What this prompt does
This prompt frames the AI as a senior application-security engineer that writes a sensitive endpoint with every security control actually implemented, not left as a TODO. You define the route with [method] and [path], the [stack], and the [auth_model]. It returns five deliverables: the full handler with strict input validation and parameterised queries, output encoding and content-type handling plus CSRF protection suited to the auth model, authorization checks that confirm the caller may access the specific resource, safe error handling that never leaks stack traces or secrets and reads config from env, and one focused test per control proving each attack is blocked.
The structure works because it pairs each defense with a test that proves the matching attack fails, so the controls are demonstrated rather than asserted. [stack] decides the framework idioms, validation library, and query layer, so the code is idiomatic rather than generic pseudocode you have to port. [auth_model] shapes the CSRF approach and the authorization checks; token-based and cookie-session models need genuinely different protections. The standout requirement is object-level access control, written together with a cross-user access test, because broken object-level access is a common and easily-missed bug that an is-logged-in check alone never catches.
When to use it
- You are building an endpoint that touches user data or sensitive resources.
- You want injection, XSS, and CSRF defenses baked in, not bolted on later.
- You need object-level authorization, not just an is-logged-in check.
- You want a test per control proving each attack path is blocked.
- You are reviewing a route and want a hardened reference implementation.
- You keep finding broken access control in reviews and want it caught early.
Example output
You get the full endpoint handler in your stack, a matching test file with one focused test per control (bad input rejected, cross-user access denied, missing token blocked), and a three-line security note listing the threats covered. The code implements strict input validation, parameterised queries, output encoding and content-type handling, CSRF protection, resource-ownership checks, and safe error handling that reads config from env, so it is meant to run against your schema, not to illustrate a pattern.
Pro tips
- Set
[stack]precisely so the validation and query code uses your framework's real idioms. - Match
[auth_model]to reality; it drives the CSRF approach and the authorization logic. - Use exact
[method]and[path]so the handler signature and routing fit your app. - Always run the deny-path tests, not just the happy path; that is where access bugs hide.
- Keep the cross-user access test; broken object-level access is the most common gap.
- Review error handling to confirm no internal IDs or secrets leak in responses.