Security review
Checks new work for the holes that let people see data that isn’t theirs.
What it does
It reviews the work you’re about to merge and checks two things: that no permission change lets someone see data that isn’t theirs, and that no new code fetches data for the wrong person. It reports what it finds in plain English, from critical to low.
How to use it
Copy the skill and paste it into a new chat, or open one with it already typed in.
Send it, and it installs the skill:
- ClaudeClick Save when it asks.
- ChatGPTSwitch to Work mode before you send it.
Then just ask: “Run a security review on this branch before I merge.”
Or use it whenever you like by typing / and choosing the /security-review skill.
Recommended
Branches
It reviews work that hasn’t been merged into staging or main. Swap in the branch names you use.
Roles
It uses ‘client’ as the example of a role that must only ever see its own data. Replace it with the roles in your app.
Admin access
It assumes ‘admin’ can see all data. If nobody in your app should see everything, delete that exception.
Don’t fix everything it flags
AI can be pretty verbose, so it’ll often flag more than you need to act on. Read through what it reports and decide what you should actually fix now and what you don’t need to worry about.
The skill in full
Show the full skill
---
name: security-review
description: Checks new work on a branch before it's merged, for changes that could let users see data that isn't theirs (permissions and data-fetching logic), plus anything deployment needs. Use before merging or shipping new work, especially in apps built with AI.
---
# Security review
I want to do a security audit of all new work that exists on my branch that has not yet been merged into staging or main.
The core points to focus on are:
- Have permissions been altered in any way? This means: have we introduced new permissions, removed permissions, altered the default permissions of a role, or changed in any way what an existing permission is able to do?
If permissions have been altered in any way, it is critical we understand the full scope of the change. At a high level, you need to ensure that no permission change now means a user is able to see data that is not directly related to them. For example, a disaster scenario would be that we grant the ‘client’ role some kind of permission that lets them see data of other clients. This would obviously be catastrophic, so it is critical we avoid this. The only exception to this rule is the ‘admin’ role. It can access all data in the app.
Likewise, we need to review all backend logic changes. The core things to cover are:
- What logic has been introduced or altered that involves fetching data?
- For this logic, do we perform the query so that the user only sees data related to them?
- If so, in plain English, how do we ensure the data belongs to them?
- If we don’t, why don’t we?
Similar to the permissions example, it would be catastrophic if we were to introduce backend logic that meant non-admin users could view data that didn’t belong to them, so it is absolutely critical we review things thoroughly.
Also, we should be aware of anything that may now require an update to something in deployment. For example, a new package we need to make sure our deployment service handles correctly, or a new environment variable that is critical for production.
I do not care how long you take to perform this review. Please do not worry about your runtime or anything of this nature. The absolute most important thing is that you perform a complete, thorough review.
Please respond in the following format, and make sure you respond in plain english that is easy for a non-technical person to understand. Style should be ASD-STE100 Simplified Technical English (STE):
Number of concerns: xx
## Critical concerns
[Insert list]
## High concerns
[Insert list]
## Medium concerns
[Insert list]
## Low concerns
[Insert list]