Review a form for security issues
Checks a form or endpoint for validation, authz, rate limits, injection and CSRF, ranked by exploitability with the attack request spelled out.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Naming the five checks explicitly stops the review from drifting into a generic "use HTTPS and sanitize input" lecture that says nothing about this particular form.
- →Requiring the concrete attacker request per finding separates theoretical risk from exploitable risk — a finding that can't be turned into an actual request usually isn't actionable yet.
- →The instruction to ask rather than assume the best or worst case keeps both false alarms and false confidence in check, since security reviews otherwise tend toward one extreme or the other.
Part by part
- report only what actually applies to what's described here — no generic security lecture
- The constraint that makes the output usable. Asked about security without it, a model returns a checklist of everything, most of which is irrelevant.
- is the check enforced server-side
- Names the distinction that matters. A client-side authorization check is a user-interface convenience and no protection at all.
- stored XSS via input rendered elsewhere
- Prompts for the second-order case, which is the one people miss — input that is safe where it is entered and dangerous where it is displayed.
- Rank findings by exploitability
- Severity ordering. An unranked list gives a missing length limit the same weight as an authorization bypass.
- give the concrete request an attacker would send
- Forces each finding to be demonstrable. A finding you can reproduce is a bug report; one you cannot is an opinion.
Common mistakes
Is this form secure?Yes-or-no framing invites a reassuring answer. Security review produces a list of specific weaknesses ranked by exploitability, and a single verdict cannot carry any of that.
Check this code for vulnerabilities.Without a named list of categories, coverage is whatever the model happens to think of, and it varies between runs. Enumerating the checks makes the review repeatable.
Review this for OWASP Top 10 issues.Produces a walk through all ten regardless of relevance, most of which do not apply to a single form. The categories in this prompt are the ones a form or endpoint can actually get wrong.
Questions
Does this replace a real security review?
No. It catches the common, well-documented classes on code you show it, and it cannot see your infrastructure, your authentication implementation, or how the endpoint composes with the rest of the system. Treat it as a first pass.
Why ask for the attacker's request?
Because it converts each finding into something you can verify yourself. A finding with a reproduction is actionable; one described in the abstract usually turns out not to apply once someone checks.
Why does it ask questions rather than assume?
Because a description rarely says whether the server re-checks authorization. Assuming the worst produces false findings that erode trust in the whole review; assuming the best hides the most serious bug class there is.
What is the single most common finding?
Authorization enforced only in the interface — the button is hidden but the endpoint still accepts the request. It is invisible in a screenshot and trivial to exploit with any HTTP client.