Q15 of 24 · Security
How do you test for security misconfiguration in a deployed web application?
Short answer
Short answer: Security misconfiguration covers missing headers, overly permissive CORS, unnecessary features enabled (directory listing, debug endpoints), default credentials, and verbose error messages. Test systematically: check response headers, probe common debug paths, test CORS preflight, and verify error messages don't reveal stack traces.
Detail
Security headers check: send a GET request to each page type (public, authenticated, API endpoint) and verify the presence of: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options or CSP frame-ancestors, and Referrer-Policy. Missing headers are findings; overly permissive values (CSP with unsafe-inline) are findings.
CORS configuration: send an OPTIONS preflight request with an Origin header from an unauthorised domain (e.g. attacker.com). Check the Access-Control-Allow-Origin response. It must not echo back the Origin header from the request (a wildcard reflection vulnerability) and must not return * for credentialed endpoints.
Debug and admin endpoints: probe common paths — /debug, /admin, /.git, /phpinfo.php, /swagger-ui, /actuator, /env, /.env. These should return 404 or 403 in production. Exposed actuator endpoints on Spring Boot applications, or Swagger UIs without authentication, are among the most common real-world findings.
Default credentials: for any admin interface or management console, test the most common default credentials (admin/admin, admin/password, root/root). This should never work — but it frequently does on internally deployed tools.
Verbose error messages: trigger a 400 (malformed request), 422 (invalid input), and 500 (provoke an error) and verify the response body does not contain a stack trace, database query, or internal file path.