Skip to main content

​
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 categoryCore question
A01 Broken Access ControlCan users do things they should not be allowed to do?
A02 Cryptographic FailuresIs sensitive data protected in transit and at rest?
A03 InjectionCan input become executable commands or queries?
A04 Insecure DesignDid the design miss necessary security controls?
A05 Security MisconfigurationAre defaults, headers, cloud settings, or permissions unsafe?
A06 Vulnerable and Outdated ComponentsAre dependencies known vulnerable or abandoned?
A07 Identification and Authentication FailuresCan users or sessions be impersonated?
A08 Software and Data Integrity FailuresCan trusted code, updates, or data be tampered with?
A09 Logging and Monitoring FailuresWould you notice and investigate an attack?
A10 Server-Side Request ForgeryCan 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.
GET /api/invoices/1001

# Attacker changes the ID:
GET /api/invoices/1002
Client-side controls are not security controls. Authorization must be enforced on the server for every sensitive action and object.

​
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

# 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

TypeTargetExample risk
NoSQL injectionMongoDB, CouchDBBypass filters or authentication
Command injectionOperating system shellExecute system commands
LDAP injectionDirectory servicesBypass directory filters
Template injectionServer-side templatesRemote code execution
Prompt injectionAI-enabled workflowsOverride 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

HeaderPurpose
Content-Security-PolicyLimits what scripts and resources can load
Strict-Transport-SecurityForces HTTPS for future visits
X-Frame-Options or CSP frame-ancestorsReduces clickjacking risk
Referrer-PolicyControls referrer leakage
Permissions-PolicyRestricts 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.
TypeHow it works
Stored XSSMalicious script is saved and later shown to users
Reflected XSSMalicious script arrives in a request and is reflected in the response
DOM XSSClient-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. 
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.