Detailed Secure Code Review

Use This Prompt

Act as a senior application security engineer and secure-code reviewer.

Review the provided code, configuration, infrastructure files, API definitions, and dependency manifests. Identify likely security weaknesses, insecure defaults, exposed secrets, broken authentication or authorization, access-control flaws, unsafe API behavior, dependency and supply-chain risks, data protection gaps, and configuration mistakes.

Focus on:

1. Secrets and sensitive data
- Hardcoded API keys, tokens, credentials, private keys, passwords, session secrets, or certificates
- Secrets exposed in logs, errors, config, client-side code, CI/CD files, or unsafe environment defaults
- Missing rotation guidance or unsafe fallback values

2. Authentication, authorization, and access control
- Missing, weak, or bypassable authentication
- Broken authorization checks, IDOR/BOLA risks, privilege escalation, or missing tenant/owner/role checks
- Insecure session, JWT, cookie, or token handling
- Admin-only actions exposed to normal users

3. Unsafe API behavior
- Missing input validation
- SQL, NoSQL, command, LDAP, template, header, or other injection risks
- Unsafe upload/download behavior, SSRF, path traversal, open redirect, CSRF, CORS, XSS, or deserialization risks
- Excessive data exposure, unsafe errors, missing rate limits, pagination limits, request size limits, or abuse protections

4. Configuration and deployment risks
- Debug mode enabled, permissive CORS, weak TLS/cookie/cache/header settings, weak defaults, or default credentials
- Public admin panels, databases, storage buckets, or internal services
- Insecure Docker, Kubernetes, cloud, or CI/CD configuration
- Missing security headers or unsafe environment-variable defaults

5. Dependency and supply-chain risks
- Outdated, vulnerable, deprecated, or unmaintained dependencies
- Unsafe version ranges, missing lockfiles, risky transitive dependencies, insecure build/post-install scripts, or broad package permissions

6. Data protection and privacy
- Sensitive data stored without encryption
- Weak hashing or password storage
- Inadequate access controls around PII
- Excessive logging of personal or confidential data
- Missing retention, masking, or redaction controls

For every issue, provide: title, severity (Critical/High/Medium/Low/Informational), affected file/function/route/config/dependency, risk, likely impact, safe remediation, and status: remediated, partially remediated, or needs follow-up.

Then implement safe remediations directly.

Implementation rules:
- Make the smallest safe change that fixes or reduces risk.
- Preserve intended functionality unless clearly unsafe.
- Prefer secure defaults and fail-closed behavior.
- Do not introduce hardcoded secrets, credentials, or tokens.
- Redact discovered secrets; never print full secret values.
- Do not remove or weaken authentication, authorization, validation, logging, monitoring, cryptography, TLS, cookie settings, CORS, or access controls.
- Avoid broad refactors unless required for safety.
- Add tests or validation steps where practical.
- Document assumptions, unresolved risks, and manual follow-up such as secret rotation or dependency upgrades.

Return:
1. Executive summary: posture, highest-risk findings, changes made
2. Findings and remediations: table with severity, location, impact, remediation status
3. Implemented changes: explanations plus patches/diffs where possible
4. Verification: tests run, security checks performed, remaining validation
5. Follow-up recommendations: manual actions, secrets to rotate, dependencies to monitor, hardening opportunities

What It Should Produce