Information disclosure in error messages
Verbose error messages can leak framework versions, stack traces, and database details. Always check error responses for version numbers that could reveal known vulnerabilities.
Security learnings from PortSwigger, infrastructure hardening, and cloud security
Verbose error messages can leak framework versions, stack traces, and database details. Always check error responses for version numbers that could reveal known vulnerabilities.
Debug endpoints like /cgi-bin/phpinfo.php can expose SECRET_KEY, database credentials, and internal paths. Look for HTML comments linking to debug pages and check robots.txt.
Backup files (.bak, .old, ~) in hidden directories can expose hardcoded credentials. Check robots.txt for /backup directories and look for files like ProductTemplate.java.bak.
Using HTTP TRACE method can reveal custom headers added by proxies/load balancers like X-Custom-IP-Authorization. These headers can be spoofed to bypass IP-based authentication.
Exposed .git directories allow full repository reconstruction. Use tools like git-dumper to extract source code, commit history, and potentially sensitive configs from /.git/.
A rule allowing get on secrets/* in a namespace exposes all secrets. Wildcards in RBAC rules can grant unintended access. Be explicit about resource names when possible.
Base images like ubuntu:latest can have hundreds of CVEs. Use distroless or alpine images, pin versions, and scan with Trivy or Grype in CI/CD pipelines.
Environment variables in CI/CD logs can leak secrets. Use secret masking, avoid printing env vars in debug output, and prefer secret management tools over plain env vars.
Setting runAsNonRoot: true, readOnlyRootFilesystem: true, and allowPrivilegeEscalation: false in pod security context blocks common container escape vectors.
Instance Metadata Service v1 at 169.254.169.254 can be accessed via SSRF to steal IAM credentials. Enforce IMDSv2 which requires session tokens and PUT requests.