/security
v0.2 · Updated Sep 22, 2026
Security is one of these issues in which developers will argue long and late into the night, and so there are a lot of different ways to approach it. Matching security to where your business is now and getting comfortable so that you can go to bed at night knowing your application is safe is a set of prompts, not one single prompt.
Kickoff prompt
Review this app for /security. Are public routes public, and are private routes or features protected? Are keys and tokens out of the code? Find the issues, then give me a plan for what to handle first, second, and third.
Subskills
Infisical is the front door. The others go after the keys and the database.
- Tools I use
Infisical
aka Infisical.com
Where secrets live once they leave a .env file or a hosted builder.
- Tools I use
The "Infisical-ator"
aka Infisical.com
Housekeeping for an Infisical account that already exists. Duplicates, shared variables, and rotation.
- On the workbench
Supabase
The data layer: auth, functions, secrets, migrations, and sign-in providers.
I wrote about this
Five things this rule looks for
- A route that should be public is locked, or a route that should be private is open.
- A feature only some people should use can be reached by anyone who knows the address.
- A key, token, or secret is sitting in the code, or in a file that gets committed.
- You can see the issues, and you do not yet have an order for first, second, and third.
- Active customers are close, and the private parts are still unprotected.