| name | web-application-security |
| description | Review web application security controls against OWASP-aligned risks. Use when building, auditing, or reviewing server-side web applications that handle user input, sessions, authentication, or access control.
|
| metadata | {"category":"secure_development","subcategory":"web-security"} |
Web Application Security
Vulnerability Classes
| Category | Threats |
|---|
| Input validation | Command injection, SQL injection, Cross-Site Scripting (XSS) |
| Upload handling | Local File Inclusion (LFI), Remote File Inclusion (RFI) |
| Session management | Man-in-the-Middle (MITM), session fixation, session hijacking |
| Data exposure | Cleartext data theft, insecure storage, cache leaks |
| Authentication | Credential stuffing, brute force, account enumeration |
| Access control | Privilege escalation, IDOR, missing function-level checks |
Security Requirements
Server-Side Controls
All security controls MUST be implemented server-side. Client-side validation is a UX convenience, not a security boundary. This applies to:
- Input validation and sanitization
- Upload type and size restrictions
- Authentication and session management
- Authorization decisions
Network-Level Protections
- Deploy a Web Application Firewall (WAF) in front of public-facing applications where feasible
- Enable DDoS protection on Internet-facing endpoints
- Terminate TLS at the edge; enforce HTTPS end-to-end
CORS
- Configure Cross-Origin Resource Sharing to allow only known, explicitly listed origins
- Never use wildcard (
*) origins on endpoints that accept credentials
- Validate the
Origin header server-side before reflecting it
CSRF Protection
- Enable framework-provided CSRF token mechanisms (e.g., Django CSRF middleware, Spring CSRF, Rails
protect_from_forgery)
- Use
SameSite cookie attributes as a defense-in-depth layer
- Verify tokens on every state-changing request
Session Management
- Generate a new session ID after successful authentication (prevent session fixation)
- Never expose session IDs in URLs
- Store session tokens in secure, HttpOnly, SameSite cookies
- Invalidate sessions on logout, idle timeout, and absolute timeout
- Bind sessions to client fingerprint where feasible (IP, User-Agent)
Sensitive Data Handling
- Encrypt sensitive data in transit (TLS 1.2+) and at rest
- Do not store sensitive data longer than necessary
- Disable caching for responses containing sensitive data (
Cache-Control: no-store)
- Never log passwords, tokens, or PII
Authentication Hardening
- Implement multi-factor authentication for privileged or Internet-facing accounts
- Use uniform error responses for login, registration, and credential recovery to prevent account enumeration (e.g., "Invalid credentials" regardless of whether the username exists)
- Enforce account lockout or progressive delays after repeated authentication failures
Access Control
- Adopt least-privilege and deny-by-default for every request
- Route all requests through a centralized access-control verification layer
- Enforce authorization on direct object references; never rely on obscurity of IDs
- Re-validate privileges on long-lived sessions
Implementation Checklist
References
