> ## Documentation Index
> Fetch the complete documentation index at: https://roadtocybersec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Web Vulnerabilities

> Learn the OWASP Top 10, access control, injection, XSS, SSRF, software integrity failures, OAuth abuse, API risks, and secure web defenses.

# Web Vulnerabilities

Web applications sit at the intersection of users, browsers, APIs, databases, cloud services, identity providers, and third-party integrations. That makes them one of the most common places where security fails.

This module focuses on the vulnerabilities developers and security professionals must understand first: broken access control, injection, insecure design, misconfiguration, vulnerable dependencies, integrity failures, SSRF, XSS, CSRF, and OAuth/API abuse.

## OWASP Top 10 as a Mental Model

The OWASP Top 10 is not a checklist of every possible bug. It is a map of recurring risk categories. Use it to ask better design, code review, and testing questions.

| OWASP category                                 | Core question                                                 |
| ---------------------------------------------- | ------------------------------------------------------------- |
| A01 Broken Access Control                      | Can users do things they should not be allowed to do?         |
| A02 Cryptographic Failures                     | Is sensitive data protected in transit and at rest?           |
| A03 Injection                                  | Can input become executable commands or queries?              |
| A04 Insecure Design                            | Did the design miss necessary security controls?              |
| A05 Security Misconfiguration                  | Are defaults, headers, cloud settings, or permissions unsafe? |
| A06 Vulnerable and Outdated Components         | Are dependencies known vulnerable or abandoned?               |
| A07 Identification and Authentication Failures | Can users or sessions be impersonated?                        |
| A08 Software and Data Integrity Failures       | Can trusted code, updates, or data be tampered with?          |
| A09 Logging and Monitoring Failures            | Would you notice and investigate an attack?                   |
| A10 Server-Side Request Forgery                | Can the server be tricked into making unsafe requests?        |

## A01: Broken Access Control

Broken access control occurs when users can act outside their intended permissions.

### Common Flaws

* **IDOR**: Changing an ID in a URL or API request to access another user's object.
* **Missing server-side authorization**: The UI hides a button, but the API endpoint still allows the action.
* **Privilege escalation**: A normal user reaches admin functionality.
* **Over-permissive roles**: Users receive broad admin rights because role design is too coarse.
* **Tenant isolation failure**: One customer can access another customer's data in a SaaS product.

```http theme={null}
GET /api/invoices/1001

# Attacker changes the ID:
GET /api/invoices/1002
```

<Warning>
  Client-side controls are not security controls. Authorization must be enforced on the server for every sensitive action and object.
</Warning>

### Defenses

* Deny by default.
* Check authorization on every request.
* Use object-level and function-level authorization.
* Log authorization failures.
* Test tenant boundaries and role boundaries.

## A02: Cryptographic Failures

Cryptographic failures expose sensitive data.

Common flaws:

* Sending sensitive data over HTTP.
* Using deprecated algorithms such as MD5, SHA-1, DES, or RC4.
* Storing passwords in plaintext or fast hashes.
* Hardcoding encryption keys.
* Misconfigured TLS.
* Logging secrets, session tokens, or personal data.

Defenses:

* Use TLS 1.2+ or TLS 1.3.
* Hash passwords with Argon2id, bcrypt, or scrypt.
* Encrypt sensitive data at rest where appropriate.
* Store keys in a secret manager or KMS.
* Redact secrets from logs.

## A03: Injection

Injection happens when untrusted input becomes part of a command, query, template, or interpreter instruction.

### SQL Injection

```python theme={null}
# Vulnerable: user input becomes SQL syntax
query = "SELECT * FROM users WHERE email = '" + email + "'"

# Safer: user input stays data
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))
```

### Other Injection Types

| Type                   | Target                 | Example risk                     |
| ---------------------- | ---------------------- | -------------------------------- |
| **NoSQL injection**    | MongoDB, CouchDB       | Bypass filters or authentication |
| **Command injection**  | Operating system shell | Execute system commands          |
| **LDAP injection**     | Directory services     | Bypass directory filters         |
| **Template injection** | Server-side templates  | Remote code execution            |
| **Prompt injection**   | AI-enabled workflows   | Override tool or data boundaries |

### Defenses

* Use parameterized queries.
* Avoid shell execution with user-controlled input.
* Validate input with allowlists.
* Encode output by context.
* Sandbox untrusted template or AI tool execution.

## A04: Insecure Design

Insecure design is not a coding typo. It is a missing or flawed control in the system design.

Examples:

* Password reset allows unlimited attempts.
* Checkout trusts client-side prices.
* Data export has no rate limits or approval workflow.
* Support staff can impersonate users without audit logging.
* A low-privilege account type can reach privileged support or admin functions.

### Defenses

* Threat model before implementation.
* Write abuse cases, not only user stories.
* Add rate limits and fraud controls.
* Make sensitive workflows auditable.
* Require approval for bulk export, admin elevation, and key rotation.

## A05: Security Misconfiguration

Misconfiguration is one of the most common real-world failure modes.

Common examples:

* Default credentials.
* Public storage buckets.
* Verbose stack traces in production.
* Missing security headers.
* Overly broad CORS.
* Debug routes left enabled.
* Excessive cloud IAM permissions.
* Exposed admin panels.

### Important Security Headers

| Header                                     | Purpose                                    |
| ------------------------------------------ | ------------------------------------------ |
| `Content-Security-Policy`                  | Limits what scripts and resources can load |
| `Strict-Transport-Security`                | Forces HTTPS for future visits             |
| `X-Frame-Options` or CSP `frame-ancestors` | Reduces clickjacking risk                  |
| `Referrer-Policy`                          | Controls referrer leakage                  |
| `Permissions-Policy`                       | Restricts browser features                 |

## A06: Vulnerable and Outdated Components

Modern applications depend on frameworks, packages, containers, plugins, and build tools. Every dependency is part of your attack surface.

Risks:

* Known CVEs in old libraries.
* Abandoned packages.
* Compromised maintainers.
* Typosquatted packages.
* Malicious install scripts.
* Transitive dependencies you never reviewed.

Defenses:

* Use dependency scanning in CI.
* Pin versions where reproducibility matters.
* Review dependency changes in pull requests.
* Remove unused packages.
* Monitor security advisories.
* Prefer packages with healthy maintenance and provenance.

## A07: Identification and Authentication Failures

Authentication failures let attackers impersonate users.

Common flaws:

* Weak password requirements with no breached-password checks.
* Missing MFA for admin accounts.
* Session tokens that never expire.
* Password reset tokens that are guessable or reusable.
* MFA bypass on legacy protocols.
* Login rate limiting missing or too weak.

Defenses:

* Use password managers and breached-password checks.
* Support phishing-resistant MFA.
* Rotate sessions after privilege changes.
* Protect password reset flows.
* Log and alert on suspicious login patterns.

## A08: Software and Data Integrity Failures

This category covers failures where software updates, CI/CD pipelines, plugins, packages, or data can be tampered with.

Recent supply chain incidents involving poisoned developer tools show why this category matters.

### Risk Patterns

* Auto-updating plugins without review.
* CI/CD workflows that run untrusted pull request code with secrets.
* Unsigned releases.
* Package registry tokens stored on developer machines.
* Build scripts that download and execute remote code.
* Webhooks that trust unsigned payloads.

### Defenses

* Require signed releases or provenance for critical artifacts.
* Protect CI/CD secrets from untrusted workflows.
* Verify webhook signatures.
* Use branch protection and review requirements.
* Rotate package publishing tokens.
* Audit package publishes and release history.

## Cross-Site Scripting

XSS occurs when untrusted data is rendered as executable script in a user's browser.

| Type              | How it works                                                           |
| ----------------- | ---------------------------------------------------------------------- |
| **Stored XSS**    | Malicious script is saved and later shown to users                     |
| **Reflected XSS** | Malicious script arrives in a request and is reflected in the response |
| **DOM XSS**       | Client-side JavaScript writes unsafe data into the page                |

### Defenses

* Encode output by context.
* Use framework defaults that escape output.
* Sanitize HTML when rich text is required.
* Use Content Security Policy.
* Avoid dangerous APIs such as `innerHTML` with untrusted data.

## Cross-Site Request Forgery

CSRF tricks a user's browser into sending an unwanted request to a site where they are already authenticated.

Defenses:

* Use SameSite cookies.
* Require anti-CSRF tokens for state-changing requests.
* Require re-authentication for sensitive actions.
* Do not use GET requests for state changes.

## A10: Server-Side Request Forgery

SSRF occurs when an attacker can make the server send requests to destinations of the attacker's choice.

```http theme={null}
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/"}
```

Impact:

* Access internal admin panels.
* Reach cloud metadata services.
* Steal cloud credentials.
* Scan internal networks.
* Bypass network restrictions.

Defenses:

* Allowlist permitted domains.
* Block internal IP ranges and metadata endpoints.
* Resolve and validate hostnames safely.
* Disable redirects unless needed.
* Use cloud metadata protections such as IMDSv2 on AWS.

## OAuth and API Abuse

Many modern web incidents involve APIs and delegated access.

Common risks:

* OAuth apps request broad scopes.
* Users grant access to malicious apps.
* API tokens never expire.
* Data export APIs have weak monitoring.
* Service accounts have admin privileges.
* Rate limits are missing for sensitive endpoints.

Defenses:

* Use least-privilege scopes.
* Require admin approval for high-risk OAuth apps.
* Rotate API keys.
* Monitor bulk exports and unusual API volume.
* Use audit logs and alerting.
* Separate service accounts by purpose.

## Practical Lab Ideas

1. Build an intentionally vulnerable IDOR endpoint and then fix it with object-level authorization.
2. Exploit SQL injection in a lab, then replace it with parameterized queries.
3. Add a strict Content Security Policy to a test app and observe what breaks.
4. Create a fake webhook and verify it with HMAC signatures.
5. Simulate SSRF against a local metadata-like endpoint and then block it.
6. Review a dependency update and identify install scripts, new transitive packages, and permissions.

## Key Takeaways

1. **Authorize on the server**.
2. **Use parameterized queries**.
3. **Design abuse resistance before coding**.
4. **Treat dependencies, plugins, and CI/CD as attack surfaces**.
5. **Protect OAuth apps and API tokens**.
6. **Log enough to investigate, not just enough to debug**.