AI can help you review code and configuration more systematically. It cannot prove that a website is secure, replace an authorized penetration test, or understand architecture you have not shown it. The useful role is narrower: a tireless second reviewer that organizes evidence, exposes missing controls, and turns findings into specific verification work.
The prompts below are designed only for websites you own or systems you are explicitly authorized to assess. They focus on source code, redacted configuration, architecture, and non-destructive verification. They do not ask the AI to attack a live target.
Before you paste anything
Redact secrets and customer data. Evidence matters more than access.
Replace passwords, tokens, private URLs, personal data, payment details, and production records with clear placeholders. If a secret has already been exposed, rotate it rather than asking an AI whether it still looks safe.
What this checklist can—and cannot—tell you
The OWASP Top 10 is an awareness document covering major web-application risks, while the OWASP ASVS provides a more detailed basis for verifying technical controls. Neither is a certificate that every possible weakness has been found. OWASP’s testing guidance also stresses that tools and checklists cannot understand every custom business-logic failure.
Treat each AI finding as a hypothesis until it cites real evidence and a human verifies it. A confident paragraph without the relevant file, route, setting, or runtime result is not a confirmed vulnerability.
01
Exposure and configuration
Begin with what is publicly reachable and how the production environment is configured.
02
Identity and access control
Verify who can sign in, what each identity may do, and where those decisions are enforced.
03
Inputs, files, and data
Trace untrusted input from the browser to every database, template, file system, and external service.
04
APIs, dependencies, and paid resources
Protect service boundaries, third-party packages, credentials, webhooks, and anything that can create cost.
05
Errors, monitoring, and recovery
Finish by checking whether the system fails safely, detects important events, and can recover.
Prepare a useful security review packet
Do not paste the entire project by default. Start with a short architecture note, then add the smallest relevant files for one prompt at a time. This keeps the model focused and makes its evidence easier to check.
✓The website's purpose, users, sensitive actions, and highest-value data.
✓Framework, hosting, identity provider, database, storage, payments, and external APIs.
✓A redacted route map showing public, signed-in, staff, and administrator surfaces.
✓The exact code or configuration relevant to one review question.
✓The intended security rule and any existing automated or manual test.
Authorization statement: I own this website or have explicit authorization to review it. Environment: - Framework and version: [provide] - Hosting and deployment: [provide] - Authentication and roles: [provide] - Database and storage: [provide] - Sensitive actions and data: [provide] Handling rules: - Treat every credential and personal value as redacted. - Review only the supplied code and configuration. - Do not scan, probe, or attack any external system. - Cite evidence for every finding and mark unknowns clearly.
01. Exposure and configuration
Begin with what is publicly reachable and how the production environment is configured.
01
Map the public attack surface
Find forgotten routes, services, dashboards, test pages, and unnecessary public features.
Act as a defensive application-security reviewer. I own or am explicitly authorized to review this website. Create an inventory of the public attack surface from the routing files, deployment configuration, and architecture notes below. Identify public pages, API routes, authentication endpoints, admin areas, uploads, webhooks, third-party callbacks, storage, and any development or diagnostic feature that appears reachable in production. For every item, state whether it must be public, should require authentication, should be restricted by role, or should not be deployed. Do not probe any domain or propose offensive testing. Project material: [paste route list, deployment configuration, and architecture notes] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
02
Check for exposed secrets and private files
Review the repository and deployment rules without pasting real credentials into the AI.
Review this redacted project structure and configuration for ways secrets or private files could become public. Look for client-side environment variables, hard-coded credentials, committed environment files, source maps, backups, database dumps, .git exposure, verbose build artifacts, and logs containing sensitive values. Important: all tokens, passwords, customer data, and private URLs have been replaced with [REDACTED]. Evaluate the storage pattern and file paths—not the secret values. Explain which variables are safe for the browser and which must remain server-side. Material: [paste redacted file tree, environment-variable names, ignore rules, and build/deployment configuration] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
03
Review HTTPS, cookies, and browser security headers
Evaluate transport and browser protections as one coherent policy.
Review the HTTPS, cookie, and security-header configuration below for a production website that I own. Check redirect behavior, HSTS suitability, Secure/HttpOnly/SameSite cookie attributes, Content-Security-Policy, frame protection, content-type sniffing protection, referrer policy, and permissions policy. Account for the actual application features and third-party domains before recommending a policy. Do not suggest a header merely to pass a scanner; explain its purpose, compatibility risk, and a safe rollout or report-only step when relevant. Configuration and response headers: [paste framework config and redacted response headers] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
04
Find insecure production defaults
Catch permissive CORS, debug output, unsafe caches, default accounts, and sample features.
Inspect this production configuration for security misconfiguration. Focus on permissive CORS, debug or test mode, detailed public errors, directory listing, default accounts, unnecessary services or sample pages, overly broad storage permissions, sensitive-response caching, weak cloud sharing defaults, and development tools enabled in production. Explain the correct production default for each confirmed issue and distinguish a real risk from a harmless development-only setting that is excluded from the production build. Configuration: [paste redacted framework, server, cloud, storage, and deployment settings] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
02. Identity and access control
Verify who can sign in, what each identity may do, and where those decisions are enforced.
05
Review registration, login, and password recovery
Check the complete identity lifecycle instead of only the login form.
Review the registration, email verification, login, logout, password-reset, and account-recovery implementation below. Look for account enumeration, unsafe reset-token handling, missing expiration or single-use behavior, weak server-side validation, session fixation, insecure error messages, and flows that leave an account in an ambiguous state. Do not request or reproduce passwords, tokens, or personal data. Use placeholders in every example. Recommend fixes that fit the existing identity provider and architecture rather than replacing the entire system without evidence. Code and flow description: [paste redacted authentication code, provider settings, and state diagram] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
06
Build and verify an authorization matrix
Make server-side access rules explicit for guests, users, staff, and administrators.
Create an authorization matrix from the routes and business rules below. For each action, identify which roles may perform it, which resource ownership rule applies, and where the server enforces the decision. Flag any permission enforced only by hidden buttons, client-side state, URL knowledge, or database filtering supplied by the browser. Apply deny-by-default and least-privilege principles. Do not give bypass instructions; focus on code and policy corrections. Roles, resources, routes, and authorization code: [paste redacted material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
07
Review session and CSRF protections
Check session creation, rotation, expiry, revocation, and state-changing requests.
Review this session-management design for a website I own. Check how sessions are created, stored, rotated after privilege changes, expired, revoked on logout or password reset, and protected in cookies. Review state-changing requests for CSRF protection appropriate to the authentication method and SameSite policy. Consider concurrent devices, stolen-session response, inactive and absolute timeouts, and whether sensitive actions require fresh authentication. Do not include attack payloads. Session configuration and request flow: [paste redacted code and settings] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
08
Review object ownership and administrator routes
Prevent users from accessing another user’s records by changing an identifier.
Review these API handlers and database queries for broken object-level authorization. Confirm that every read, update, export, and delete operation derives the authenticated identity on the server and verifies ownership or an explicit privileged role. Pay special attention to IDs in URLs or request bodies, bulk operations, exports, support tools, and administrator routes. Do not demonstrate how to access another user’s data; identify the missing server-side checks and show a safe authorization pattern using placeholders. Handlers, schemas, and role rules: [paste redacted code] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
03. Inputs, files, and data
Trace untrusted input from the browser to every database, template, file system, and external service.
09
Create an input-validation boundary map
Identify where data enters, how it is normalized, and where server-side validation is missing.
Map every untrusted input in the code below: form fields, URL parameters, headers, cookies, uploaded metadata, webhook bodies, and third-party API responses. Trace each value to its validation, normalization, authorization decision, storage, rendering, or outbound request. Flag validation that exists only in the browser, inconsistent schemas between routes, dangerous type coercion, missing size limits, and allowlists that are broader than the business requirement. Recommend one authoritative server-side validation point per boundary. Code and schemas: [paste relevant routes, forms, and validation code] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
10
Review injection defenses
Inspect database, HTML, command, template, and outbound-request sinks without generating payloads.
Perform a defensive code review for injection risk. Locate places where untrusted input reaches SQL or NoSQL queries, HTML or templates, shell or process execution, file paths, email headers, log messages, or outbound URLs. Check for parameterized queries, context-appropriate output encoding, safe APIs, explicit allowlists, and separation between data and commands. Do not create exploit strings or instructions for testing a live target. Show focused safe code patterns only for confirmed risks. Relevant code: [paste redacted handlers, queries, templates, and integrations] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
11
Review file-upload safety
Check type, size, storage, naming, access, scanning, and safe delivery.
Review this file-upload flow from selection to storage and download. Check server-side size limits, allowed file types, content inspection, generated filenames, path handling, storage outside executable web roots, access control, malware-scanning hooks where appropriate, image or document processing, download headers, deletion, and retention. Assume filenames, MIME types, and client metadata are untrusted. Do not supply malicious sample files or payloads. Recommend controls proportionate to the allowed file types and user workflow. Upload code, storage policy, and allowed formats: [paste redacted material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
12
Minimize personal and sensitive data
Find information the product collects, stores, returns, or logs without a clear need.
Create a data-flow review from the schemas, API responses, analytics, logs, backups, and retention rules below. Identify personal, authentication, billing, prompt, and operational data; where it enters; who can access it; why it is needed; how long it remains; and how it is deleted. Flag excessive collection, sensitive fields returned to the browser, secrets or personal data in logs, indefinite retention, broad administrator access, and unclear deletion behavior. Do not ask me to paste real customer records. Redacted schemas and data-flow notes: [paste material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
04. APIs, dependencies, and paid resources
Protect service boundaries, third-party packages, credentials, webhooks, and anything that can create cost.
13
Review dependencies and the software supply chain
Turn a dependency inventory into an ownership and update plan.
Review this dependency manifest, lockfile summary, build workflow, and update policy for software-supply-chain risk. Identify packages that appear unnecessary, unmaintained, unusually privileged, loaded from untrusted sources, missing integrity pinning, or allowed to execute risky install scripts. Do not claim a package is vulnerable without a verifiable advisory and version match. Separate confirmed advisories from maintenance concerns, explain the compatibility risk of each upgrade, and propose a staged update and verification plan. Dependency and build material: [paste manifests, redacted workflow, and scanner output] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
14
Check API keys and privileged operations
Keep permanent credentials and authorization decisions outside browser code.
Review this frontend-to-backend-to-provider architecture. Identify every API key, database credential, payment secret, service token, and privileged operation, using variable names only—never values. Confirm that permanent secrets are stored in protected server settings, excluded from client bundles and logs, scoped to minimum privilege, rotated when exposed, and not trusted merely because a request came from my frontend. Flag any business rule or paid provider call that a visitor can invoke without server-side authentication, validation, and usage controls. Architecture and redacted code: [paste material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
15
Review rate limits and resource controls
Prevent one user or automated client from exhausting compute, storage, email, or model spend.
Review the controls around expensive or limited operations in this application: AI calls, email, uploads, search, exports, login attempts, password resets, database queries, and third-party APIs. For each operation, identify the trusted server-side identity or key, request and output size limits, concurrency and timeout controls, user and global quotas, retry behavior, idempotency, cost alerts, and safe failure response. Flag limits implemented only in browser storage or client code. Routes, limits, and billing architecture: [paste redacted material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
16
Review webhook verification and replay safety
Confirm that payment and integration events are authentic and processed once.
Review this webhook endpoint for defensive correctness. Check that it reads the raw request body when required, verifies the provider signature with a server-side secret, rejects invalid or stale events, handles retries and duplicate event IDs safely, makes state changes idempotent, and records enough metadata for investigation without logging sensitive payloads. Confirm that an event cannot grant access, credit, or subscription status based only on client-supplied fields. Do not provide signature-forging or replay instructions. Webhook handler and provider requirements: [paste redacted code and official contract] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
05. Errors, monitoring, and recovery
Finish by checking whether the system fails safely, detects important events, and can recover.
17
Review safe error handling
Keep public errors useful without exposing internals or leaving partial state behind.
Review error handling across these routes and user flows. Identify places where stack traces, component versions, queries, filesystem paths, provider responses, secrets, or personal data could reach the browser. Check that multi-step writes fail atomically or are compensated, timeouts and upstream failures produce controlled states, and public messages remain actionable without revealing internals. Recommend protected diagnostic logging for developers and stable generic responses for users. Error-handling code and sample redacted responses: [paste material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
18
Design security logging and alerts
Record high-value events without building a new sensitive-data leak.
Design a focused security logging and alerting plan for this application. Cover authentication and recovery events, authorization denials, server-side validation failures, privilege changes, administrator actions, webhook failures, rate-limit events, unusual usage, and changes to sensitive settings. For each event, specify the minimum useful fields, fields that must never be logged, retention and access considerations, alert threshold, owner, and response action. Avoid recording passwords, tokens, complete payment data, private prompt contents, or unnecessary personal information. Architecture, existing logs, and operational constraints: [paste redacted material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
19
Review backups and recovery
Confirm that backups are protected, restorable, and aligned with the product’s data promises.
Review this backup and disaster-recovery plan. Check what is backed up, encryption and access control, separation from production credentials, retention, deletion propagation, regional or provider dependencies, restore testing, recovery time and recovery point objectives, and the procedure for a failed deployment or corrupted database. Identify claims that have never been tested and propose a safe restore rehearsal using non-production or sanitized data. Do not request production credentials or customer records. Backup architecture and recovery notes: [paste redacted material] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
20
Create a prioritized remediation plan
Convert findings into an ordered plan with owners and proof of completion.
Consolidate the defensive security findings below into a remediation plan for the website owner. Remove duplicates and rank issues using exploitability, realistic impact, affected users and data, internet exposure, existing controls, and confidence in the evidence. Create four queues: fix immediately, fix this sprint, schedule, and accept or monitor. For every item include the owner, smallest safe change, dependencies, rollback plan, verification evidence, and remaining risk. Never upgrade severity simply because a finding sounds technical. Clearly mark anything that requires a qualified security professional to validate. Findings: [paste sanitized findings from the previous reviews] Required output: Return a findings table with these columns: - Severity: critical, high, medium, low, or informational - Evidence: exact file, setting, route, or code excerpt - Risk: the realistic failure or exposure - Recommended fix: the smallest safe correction - Verification: a non-destructive way to confirm the fix - Confidence and missing evidence Do not invent files, settings, or successful tests. Do not provide exploit payloads or instructions for attacking a live system. Separate confirmed findings from recommendations.
How to evaluate the AI’s security findings
A useful response makes the next decision easier. It distinguishes a proven weakness from a missing control, gives the exact evidence, recommends a change appropriate to your stack, and explains how to verify the result without damaging data or disrupting users.
✓Every confirmed finding cites an exact file, route, setting, or observed result.
✓Severity reflects realistic exposure and impact—not dramatic language.
✓The fix addresses the root cause and preserves required product behavior.
✓Verification is non-destructive and can be repeated after future changes.
✓Unknowns and assumptions are visible instead of being presented as facts.
✓Critical, payment, identity, or sensitive-data findings receive qualified human review.
The defensive workflow
Review one boundary at a time. Require evidence. Fix the highest realistic risk. Verify the correction. Then preserve the check so the same problem does not return in the next release.
Prepare a clearer review
Optimize your website-security prompt with Prompt.Lab.
Describe the part of your own website you want reviewed, add the relevant stack and constraints, and turn the rough request into a structured brief. Open the free prompt optimizer →