Evidence-Based Code Security Review Prompt

Public field comparison

Security Review Prompt

Evidence-Based Code Security Review Prompt

Review code for auth, authorization, input handling, secrets, unsafe queries, file exposure, and practical hardening steps.

Use Codex to inspect application code for authentication, authorization, injection, unsafe input handling, secret exposure, file-access flaws, and release-blocking security risks.

—

Produce a traceable code security assessment with evidence-backed findings, severity rationale, remediation guidance, validation procedures, and an explicit release recommendation.

Security Review
Code Review Planning
Regression Testing
Debugging Plan
Release Verification

Application code security assessment
Authentication and authorization review
Injection and sensitive-data exposure analysis
Security remediation verification
Pre-release security risk review

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Review objective
Repository materials
System context
Security requirements
Execution permissions
Validation commands
Definition of done

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

Open Codex, replace every bracketed variable, and provide the relevant repository files or accessible codebase, dependency manifests and lockfiles, configuration examples, architecture and trust-boundary context, security requirements, execution permissions, logs or prior findings, and approved test commands. Then run the prompt. Use a non-production environment for authorized validation and retain human approval for edits, risk acceptance, and release decisions.

Use this when you need a production-ready security review result in Codex & Coding, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

Before releasing a multi-tenant API, give Codex the target revision, route and middleware files, authorization policies, database queries, upload handlers, dependency lockfile, architecture notes, and approved test commands. The prompt produces a scoped attack-surface map, evidence-linked findings, role and tenant regression tests, remediation guidance, and a bounded release recommendation without claiming unexecuted work succeeded.

Expert

Expert

Codex

Codex

security review

security review

codex
Codex & Coding
security
review
hardening

codex
code security
application-security
authorization
security testing
secure code review

Security Review Prompt | AMO.ng

Evidence-Based Security Review Prompt for Codex | AMO.ng

Review code for auth, authorization, input handling, secrets, unsafe queries, file exposure, and practical hardening steps.

Use Codex to review authentication, authorization, injection, secrets, files, dependencies, and release risks with traceable evidence.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Codex & Coding specialist using Codex. Your task is: [Goal or task].
+Conduct a code-level security review in Codex using the following inputs.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Review objective: [Review objective]
+Repository materials: [Repository materials]
+System context: [System context]
+Security requirements: [Security requirements]
+Execution permissions: [Execution permissions]
+Validation commands: [Validation commands]
+Definition of done: [Definition of done]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Security Review Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Input and access rules
+- Treat the review objective and inspectable repository materials as minimum prerequisites. The materials should include the relevant source files or repository, dependency manifests and lockfiles, configuration examples, database or API boundaries, and tests when available.
+- System architecture, trust boundaries, data classifications, deployment configuration, known threats, prior findings, and applicable security requirements are useful context. Mark them unknown when they are not supplied.
+- If no relevant code or configuration is accessible, stop the code-level assessment. Return a blocking-input list and review plan rather than security conclusions.
+- Ask a clarification question only when an ambiguity prevents safe scoping, severity assignment, or interpretation of an access-control rule. Otherwise, proceed with a bounded review and record the limitation.
+- If supplied materials conflict, identify the conflict, cite both sources, and do not silently choose one.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Codex operating boundaries
+- Use Codex to inspect only the files and repository context actually available in the session. Do not imply access to services, branches, secrets, logs, infrastructure, tickets, or production environments that Codex cannot access.
+- Read and analyze within the granted scope. Run only the validation commands explicitly authorized by the execution permissions and only in an approved non-production environment.
+- Do not deploy, merge, commit, push, rotate or reveal secrets, alter accounts or permissions, modify production data, contact third parties, or approve a release.
+- Do not perform destructive tests, denial-of-service tests, credential attacks, persistence, data exfiltration, or exploitation beyond the minimum safe proof needed to establish a finding. Stop if a command could expose sensitive data, affect production, cross an authorization boundary, or cause irreversible changes.
+- Redact credentials, tokens, personal data, private keys, and sensitive business data from the report. Refer to secret locations without reproducing secret values.
+- Code changes are proposals unless the execution permissions explicitly authorize edits. Before any authorized edit, describe the files affected, security intent, compatibility risk, validation plan, and rollback method. Keep human approval as the gate for consequential changes and release decisions.
 
−Do not give generic advice. Optimize for a production-quality security review outcome.
+Evidence model
+Maintain these distinctions throughout the review:
+- Supplied fact: context stated by the user but not independently demonstrated in the available materials.
+- Observation: behavior or code directly visible in an accessible file, with file path and line or symbol reference.
+- Execution evidence: a command actually run in this session, including command, environment, exit status, and relevant redacted output.
+- Assumption: a bounded interpretation required to continue.
+- Hypothesis: a plausible security issue that still requires evidence.
+- Unknown: information unavailable from the supplied scope.
+- Conflict: incompatible evidence or requirements that require reconciliation.
+
+Never present a hypothesis, scanner alert, pattern match, or dependency advisory as a confirmed exploitable vulnerability without tracing the relevant data flow, control flow, configuration, affected version, or reachable call path. State when line numbers are approximate or generated files reduce traceability.
+
+Review procedure
+1. Establish scope and attack surface
+   - Inventory the inspected files, languages, frameworks, dependency manifests, externally reachable endpoints, background jobs, administrative functions, file-processing paths, data stores, and third-party integrations visible in scope.
+   - Map trust boundaries and principal types such as anonymous users, authenticated users, tenants, administrators, services, and webhook senders.
+   - Record excluded components and explain how each exclusion limits assurance.
+
+2. Trace identity and session controls
+   - Inspect login, registration, password reset, account recovery, multifactor flows, API-key handling, token creation and validation, session rotation, logout invalidation, cookie attributes, token expiry, and replay resistance where present.
+   - Check for authentication bypasses, user enumeration, insecure default credentials, weak token validation, confused identity sources, and inconsistent enforcement between web, API, job, and internal routes.
+
+3. Test authorization logic by resource and action
+   - Trace how each sensitive endpoint or operation establishes the acting principal, requested resource, tenant ownership, role, and permitted action.
+   - Look for missing object-level and function-level authorization, insecure direct object references, tenant-boundary failures, privilege escalation, mass assignment, hidden-field trust, administrative route exposure, and checks performed only in the client.
+   - Distinguish authentication from authorization; the presence of a logged-in user is not evidence that access is permitted.
+
+4. Follow untrusted input to security-sensitive sinks
+   - Identify request fields, headers, cookies, uploaded files, webhook payloads, queue messages, imported records, and third-party responses that cross trust boundaries.
+   - Trace validation, normalization, canonicalization, encoding, and type enforcement to SQL, NoSQL, shell, template, HTML, URL fetch, deserialization, logging, filesystem, redirect, and dynamic evaluation sinks.
+   - Evaluate injection, cross-site scripting, server-side request forgery, path traversal, open redirect, request smuggling assumptions, unsafe deserialization, command execution, and log-forging risks as applicable to the actual stack.
+   - Prefer parameterization and context-specific output encoding. Do not treat blocklists or client-side validation as sufficient controls.
+
+5. Review secrets, cryptography, and sensitive data handling
+   - Check source, configuration, fixtures, logs, error paths, build files, and client bundles for embedded credentials or unintended sensitive-data disclosure without reproducing any discovered value.
+   - Inspect key and token storage, randomness, password hashing, encryption modes, signature verification, certificate validation, key separation, rotation support, and fail-open behavior where relevant.
+   - Verify that sensitive fields are minimized and protected in logs, caches, analytics, backups, URLs, error messages, and API responses.
+
+6. Review database, file, and network boundaries
+   - Inspect query construction, row or tenant scoping, transaction boundaries, race conditions, unsafe raw queries, and excessive database privileges visible in configuration.
+   - For uploads and downloads, check filename canonicalization, extension and content validation, size limits, storage location, execution permissions, archive extraction, access checks, content disposition, malware-scanning hooks, and cleanup behavior.
+   - For outbound requests and webhooks, inspect destination allowlisting, redirect handling, DNS and private-network protections, timeouts, response limits, signature validation, replay controls, and error handling.
+
+7. Review security configuration and dependency exposure
+   - Examine debug modes, verbose errors, CORS, CSRF protections, security headers, cookie settings, rate limits, proxy trust, environment separation, default routes, feature flags, and fail-open defaults.
+   - Compare dependency versions against supplied lockfiles and available advisory evidence. Account for reachability, affected version ranges, mitigations, and uncertainty; do not infer compromise from version presence alone.
+
+8. Analyze abuse cases and operational failure modes
+   - Consider brute force, replay, duplicate requests, concurrency, stale authorization, cache confusion, race conditions, partial failures, retries, queue redelivery, oversized inputs, malformed encodings, and cross-tenant access.
+   - Identify controls that exist but can be bypassed through alternate endpoints, asynchronous workers, internal APIs, legacy paths, or inconsistent middleware ordering.
+
+9. Triage and recommend remediation
+   - Assign each confirmed finding a unique identifier and severity of Critical, High, Medium, Low, or Informational.
+   - Explain severity using exploit preconditions, required privileges, reachability, affected assets, confidentiality/integrity/availability impact, tenant or user scope, detectability, and compensating controls. If these factors are unknown, lower confidence rather than inventing them.
+   - Separate confirmed findings from hypotheses and hardening opportunities. Avoid duplicate findings that share one root cause.
+   - Propose the smallest robust fix at the correct enforcement layer. Include compatibility, migration, performance, usability, observability, and rollback considerations.
+
+10. Verify safely
+   - For each finding, define a reproducible validation procedure with prerequisites, a benign test input or unit/integration test design, expected secure behavior, expected vulnerable behavior when safe to describe, and required evidence.
+   - Run a procedure only when access and execution permissions allow it. Record the exact command, environment, exit status, and redacted result. Otherwise mark it Not run and state why.
+   - Include positive tests, negative tests, authorization tests across relevant roles or tenants, regression tests for the root cause, and checks that the remediation does not create a fail-open path.
+   - Reconcile static observations with execution results. Preserve discrepancies as unresolved instead of choosing the preferred result.
+
+11. Determine handoff state
+   - Identify release blockers, accepted residual risks requiring owner approval, unresolved hypotheses, missing evidence, and dependencies on infrastructure or operational controls outside the repository.
+   - Recommend one of: Hold for remediation, Conditional review required, or No release-blocking issue identified in reviewed scope. The last state is not a declaration that the system is secure.
+   - A human security or engineering owner must approve remediation, risk acceptance, and release decisions.
+
+Required deliverable
+
+A. Scope and assurance statement
+- Review objective and definition of done
+- Materials inspected, including commit or revision when available
+- Components, environments, and threat actors considered
+- Exclusions, unknowns, conflicts, assumptions, and their effect on assurance
+- Commands authorized, commands executed, and tools or data unavailable
+
+B. Attack-surface and control map
+Provide a table with: component or entry point; principal; trust boundary; sensitive asset or operation; authentication control; authorization control; untrusted inputs; sensitive sinks; relevant security requirement; evidence reference.
+
+C. Confirmed finding register
+For every confirmed finding provide:
+- Finding ID and concise title
+- Severity and confidence
+- Affected component, file path, line or symbol, endpoint or operation
+- Security property violated and plausible abuse scenario
+- Preconditions, required privileges, reachability, and affected scope
+- Evidence trace from source to control or sink
+- Existing and missing controls
+- Impact and severity rationale
+- Minimal safe reproduction or test design
+- Remediation at the root enforcement point
+- Trade-offs, compatibility concerns, migration needs, and rollback approach
+- Verification procedure, expected result, actual result if executed, and evidence reference
+- Status: Confirmed-unfixed, Proposed remediation, Edited-not-tested, Tested-not-remediated, Verified-remediated, Blocked, or Risk-accepted with named human approval evidence
+
+D. Hypotheses and hardening register
+List unconfirmed concerns and defense-in-depth improvements separately. For each include the triggering observation, missing evidence, potential impact, and the next evidence needed. Do not assign confirmed-vulnerability language to this section.
+
+E. Validation matrix
+Provide a table with: finding ID; test type; authorized environment; command or procedure; expected secure observation; actual observation; evidence; result of Pass, Fail, Not run, or Inconclusive; follow-up owner.
+
+A Pass requires an executed test whose actual observation matches the expected secure behavior. Code inspection alone may support a finding but must not be described as an executed test. If edits were made but tests were unavailable or failed to run, report Edited-not-tested rather than fixed or verified.
+
+F. Release and remediation handoff
+- Prioritized remediation order based on exploitability and impact
+- Release blockers and rationale
+- Required human approvals and risk owners
+- Residual risks, monitoring or detection recommendations, and rollback triggers
+- Final recommendation using one permitted handoff state
+- Smallest safe next action
+
+Completion language
+- Use fixed, remediated, tested, verified, approved, deployed, or completed only when the corresponding action occurred and supporting evidence is cited.
+- Never claim that an unexecuted command passed, a proposed patch was applied, an unavailable environment was inspected, or a release was approved.
+- If no confirmed findings are identified, say only that no confirmed findings were identified within the reviewed scope and evidence; do not claim the application is secure.