Skip to main content

Claude/ChatGPT (or Copilot) Prompt for Security-Aware Endpoint Code

Generate a sensitive API endpoint with injection, XSS, CSRF, and access-control defenses baked in, plus a test per control.

Fill in the placeholders

Edit the values, then copy your finished prompt.

Your Prompt
prompt.txt

                                

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.

Frequently Asked Questions

Does it implement the security controls or just comment them as TODOs?
It is instructed to write working code with every control implemented, not commented as a TODO. That includes validation, parameterised queries, output encoding, CSRF, and authorization. You should still review and test the result against your real schema, since the model only sees the context you provide.
Does it cover object-level access control specifically?
Yes, and this is a deliberate emphasis. Deliverable three requires checks that confirm the caller owns or may access the specific resource, not merely that they are logged in, and it pairs that with a cross-user access test. Broken object-level access is exactly the gap this prompt targets.
Will it work for my framework and auth setup?
It adapts to whatever you put in `[stack]` and `[auth_model]`, so it can target Express, Laravel, Django, or others with JWT, sessions, or another scheme. Naming both precisely is what makes the validation, CSRF approach, and authorization checks idiomatic rather than generic.
Are the generated tests enough to call the endpoint secure?
The tests prove the named attack paths are blocked, which is a strong baseline, but they are not a full security audit. Use them as a starting point, run the deny paths, and complement them with your own threat review for risks specific to your application.
Engr Mejba Ahmed

Need this built for real?

Engr Mejba Ahmed

AI Developer · Software Engineer

I'm Mejba — I design and ship production AI systems, automations, and full-stack apps. If you want this turned into a working solution for your team, let's talk.

More in GitHub Copilot Prompts

Engr Mejba Ahmed

Engr Mejba Ahmed

Claude Code Expert · Online

👋

Hey there!

Quick Actions

WhatsApp Instant reply

Chat on WhatsApp

+880 1723 741224 · Instant reply

Popular Questions

Engr Mejba Ahmed is connected
Engr Mejba Ahmed is typing...
Engr Mejba Ahmed avatar

✉ Want me to follow up? Drop your email

Engr Mejba Ahmed avatar

📞 Connect Directly

Choose how you'd like to reach me

WhatsApp

+880 1723 741224

Email

[email protected]

✓ Details sent! I'll get back to you shortly.

Powered by OpenAI

335+

Blog Posts

25

AI Courses

63

Projects

Services & Expertise

Pricing & Process

Learning & Resources

Connect & Support