Cybersecurity Roadmap

Learn how to secure networks, applications, and systems against digital threats.

Overall Progress0%

Web Application Security

Explanation

Web applications are the most exposed software most organizations run: anyone on the internet can reach them. Web application security is about controlling that exposure — validating and encoding every input, protecting sessions and identities, and enforcing authorization on every request. This lesson covers the OWASP-style fundamentals: the attack surface, authentication and authorization, the major vulnerability classes (XSS, CSRF, SQL injection, IDOR, broken access control, misconfiguration, file upload, path traversal, SSRF), and the defensive controls that stop them. For each major vulnerability you will learn what it is, why it happens, what an attacker aims to achieve, a deliberately simplified toy example, the impact, and how to prevent and detect it. Everything is educational, local, and contained.

The Web Application Attack Surface

Every input: forms, URLs, headers, cookies, uploaded files.
Authentication and session management.
Authorization and access-control checks.
Server configuration and exposed services.
APIs and third-party integrations.

HTTP, Cookies, and Sessions

HTTP is stateless: each request is independent. Cookies and session tokens let a server remember a user across requests. That state is valuable to attackers, so it must be protected.

Concept	Role	Risk if mishandled
Cookie	Stores state in the browser	Session hijacking if stolen or predictable
Session token	Identifies the logged-in user	Account takeover if leaked
Request/response	The channel of interaction	Tampering or injection via untrusted input

Authentication and Authorization

Authentication proves who you are; authorization decides what you may do.
Enforce authorization on the server for every request, not just in the UI.
Never rely on client-side checks alone.

Input Validation and Output Encoding

Validate input: accept only what is expected (allowlists over denylists).
Encode output: render untrusted data as data, never as code or markup.
Context matters: encode differently for HTML, JavaScript, and URLs.

Cross-Site Scripting (XSS)

XSS occurs when an application renders untrusted input as HTML or JavaScript, letting an attacker run script in a victim’s browser.

Type	Where the payload lives	Typical trigger
Stored XSS	Persisted on the server (a comment, a profile)	Every visitor who views it
Reflected XSS	Echoed from the request (a search term)	A crafted link the victim clicks
DOM XSS	Processed by client-side JavaScript	Manipulating the page state

XSS: What, Why, Impact, Prevention

What: attacker-supplied script executes in a victim’s browser.
Why: untrusted data is rendered without encoding.
Impact: session theft, defacement, phishing, keylogging.
Prevent: encode output in the correct context; validate input.
Detect: review how user data reaches the page; use a Content Security Policy.

Cross-Site Request Forgery (CSRF)

CSRF tricks an authenticated user’s browser into making an unintended request to a site where they are logged in, riding on their existing session.

Why: the browser automatically attaches the session cookie.
Impact: unwanted actions such as changing a password or transferring money.
Prevent: anti-CSRF tokens, SameSite cookies, and verifying the request origin.

SQL Injection

SQL injection occurs when user input is concatenated into a SQL query, letting an attacker alter the query’s meaning.

python

1# Vulnerable: string formatting builds the query2name = request.get('name')3query = "SELECT * FROM users WHERE name = '" + name + "'"4 5# If name is:  ' OR '1'='16# the query becomes:7#   SELECT * FROM users WHERE name = '' OR '1'='1'

Impact: data theft, modification, or deletion.
Prevent: parameterized queries / prepared statements.
Detect: code review and web application scanning.

IDOR / Broken Object-Level Authorization

IDOR: a resource is referenced by a predictable identifier with no check that the requester may access it.
Why: authorization is checked only in the UI, not on the server.
Impact: reading or modifying other users’ data.
Prevent: verify object ownership and authorization on every request.

Broken Access Control

Missing server-side checks on sensitive actions.
Exposed admin endpoints reachable by normal users.
Client-side hiding of controls instead of server enforcement.

Security Misconfiguration

Default credentials and debug modes left enabled.
Unnecessary features, ports, or directories exposed.
Missing security headers or overly permissive CORS.
Error pages that leak stack traces and internals.

File Upload and Path Traversal

File upload: validate type and content; never serve executable uploads from the same origin.
Path traversal: user input such as ../ must not control filesystem paths.
Prevent: allowlist extensions, rename files, and constrain paths.

SSRF (Server-Side Request Forgery)

SSRF makes the server itself issue requests to an attacker-chosen URL. Because the request comes from the trusted server, it can reach internal systems such as metadata endpoints.

Why: the server fetches a user-supplied URL without restriction.
Impact: reaching internal services or cloud metadata.
Prevent: allowlist destinations, block internal ranges, and validate URLs.

Session Security and Password Handling

Issue strong, random session tokens; rotate on login.
Set cookies with HttpOnly, Secure, and SameSite.
Hash passwords with a slow, salted algorithm (bcrypt/Argon2).

Security Headers, CORS, and HTTPS

Control	Purpose
HTTPS (TLS)	Confidentiality and integrity in transit
Content-Security-Policy	Restricts what scripts and resources may load
Strict-Transport-Security	Forces HTTPS
CORS policy	Controls which origins may read responses

Secure API Design, Rate Limiting, and Monitoring

Validate and authorize on every endpoint.
Rate-limit to blunt brute force and abuse.
Log and monitor authentication failures and anomalous activity.
Return generic errors to users; log details server-side.

Vulnerability to Impact: The Full Chain

Vulnerability

↓

Exploit

↓

Impact

↓

Mitigation

↓

Detection

For every finding, reason about the whole chain: the weakness, how it is exploited, the harm it causes, how to prevent it, and how to detect it.

Examples

A toy reflected XSS

A search page echoes the query into HTML without encoding.

text

1Input:   <script>alert(1)</script>2Vulnerable output:3  You searched for: <script>alert(1)</script>4Safe output (encoded):5  You searched for: &lt;script&gt;alert(1)&lt;/script&gt;

Output

(encoding renders the input as text, not script)

A toy SQL injection vs parameterized query

The same login query written unsafely and safely.

python

1unsafe = "SELECT * FROM users WHERE name = '" + name + "'"2safe  = "SELECT * FROM users WHERE name = %s"  # bound with (name,)

Output

(the parameterized query treats input as data, never as SQL)

Key Takeaways

Validate input on the way in and encode output on the way out.
XSS, CSRF, SQLi, IDOR, and SSRF share one cause: trusting untrusted data.
Enforce authorization on the server for every request.
Use parameterized queries; hash passwords with bcrypt/Argon2.
Protect sessions with HttpOnly/Secure/SameSite cookies.
Reason in full chains: vulnerability → exploit → impact → mitigation → detection.

← PreviousCloud Security Next →Secure Coding & SAST