CWE-287: Improper Authentication

Overview

This guidance helps interpret DAST findings for CWE-287: Improper Authentication. During dynamic scanning, the scanner detected that requests succeeded without valid credentials, with invalid/expired tokens, or with client-supplied identity values that are not properly verified server-side.

What the DAST scanner detected:

Bypassed authentication: Protected endpoints accessible without authentication headers/cookies
Invalid token acceptance: Expired, malformed, or unsigned JWTs accepted
Credential stuffing susceptibility: No rate limiting or account lockout on login attempts
Default credentials: Common username/password combinations accepted (admin/admin, root/password)
Authentication logic flaws:
- Client-side authentication checks only (JavaScript validation)
- Predictable session tokens or sequential IDs
- Missing authentication on API endpoints while UI is protected
HTTP method bypass: GET /admin requires auth, but POST /admin does not
Token replay: Same token works after logout or from different IP addresses

Key DAST evidence:

Accessing /api/users without Authorization header returns 200 OK with user data (should return 401)
Modified JWT with "alg": "none" or invalid signature still accepted
Same session cookie valid after explicit logout
Login successful with credentials test@example.com / password123 (default creds)
Response identical for valid user/wrong password vs invalid user (username enumeration)
200 OK for /admin/delete-user without authentication, 302 redirect only on web UI

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

DAST findings typically show that requests succeed without valid credentials, with invalid or expired tokens, or with client-supplied identity values that are not properly verified server-side.

When reviewing your security scan results, you'll see:

HTTP Request Details

URL and endpoint that triggered the finding
HTTP method (GET, POST, etc.)
Query parameters or form data with test payloads
Request headers and body content

HTTP Response Evidence

Response showing the vulnerability manifestation
Evidence of improper handling or of missing or bypassable authentication
Runtime behavior indicators

Attack Vector

Which parameter or input is vulnerable
Type of exploitation possible
Context where the vulnerability appears

Mapping DAST Findings to Source Code

Find the Vulnerable Endpoint

Use the HTTP request URL to locate the code:

# Search for authentication endpoints
grep -r "/login" src/
grep -r "/auth" src/
grep -r "/verify" src/
grep -r "@login_required" src/
grep -r "authenticate" src/

Locate the Authentication Handler

Common patterns to search for:

Python Flask/Django: @login_required, authentication middleware
Node.js Express: passport.authenticate(), auth middleware
Java Spring: @Secured, @PreAuthorize, Spring Security config
ASP.NET: [Authorize], authentication filters
PHP: Session checks, password verification

Find Authentication Logic

Search for authentication code:

# Find authentication checks
grep -r "password_verify" src/               # PHP
grep -r "bcrypt.compare" src/                # Node.js
grep -r "check_password" src/                # Python
grep -r "PasswordEncoder" src/               # Java Spring
grep -r "PasswordHasher" src/                # .NET

Trace to Vulnerable Operation

Look for authentication weaknesses:

Missing authentication: Protected resources accessible without login
Weak password checks: Insecure comparison, no rate limiting
Bypassable logic: Client-side checks, URL tampering
Token validation: Missing or improper JWT/session validation
Default credentials: Hardcoded or well-known passwords

Remediation

Core Principle: Never trust client-supplied identity; every request must be authenticated by the server using a complete, validated authentication mechanism before any identity or session is accepted.

Authentication must be enforced before any identity, session, or token is accepted
Identity must be derived exclusively from server-validated credentials, not client input
Authentication checks must be consistent across all request paths and methods

→ For comprehensive remediation guidance, see Static CWE-287 Guidance

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Test authentication bypass
curl "http://localhost:3000/admin"  # Without credentials
curl "http://localhost:3000/api/users" -H "Authorization: Bearer invalid_token"

# Or use browser DevTools

Verify the Fix

Confirm all protected resources require valid authentication
Verify strong password hashing (bcrypt, Argon2)
Check rate limiting on login attempts
Ensure session/token validation is enforced
Test that authentication cannot be bypassed

Test Edge Cases

These tests verify that authentication logic cannot be bypassed via malformed input, not that injection itself is present.

# Access without credentials
/admin
/api/sensitive-data

# Invalid token/session
curl -H "Authorization: Bearer fake_token" "/api/users"
curl -H "Cookie: session=invalid" "/dashboard"

# SQL injection in auth
/login?username=admin'--&password=anything

# Empty password
/login?username=admin&password=

# Case manipulation
/login?username=Admin&password=password

# NoSQL injection
/login -d '{"username":{"$ne":null},"password":{"$ne":null}}'

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.