In Log 14, I successfully cleaned the code — Attempt 2 of the Three-Attempt Protocol. It was lean, readable, and fully documented. But clean code is not necessarily secure code.
A login form can be perfectly written, use the right variable names, and follow every style guide — and still be open to a SQL injection or a session hijack. Attempt 3 is not about coding. It is about security hardening. It is the process of moving from “this works” to “this survives.”
The Realization: I Do Not Know What I Do Not Know
I am not a security researcher. I do not know the current exploit patterns for Python libraries or the subtle flaws in session management.
If I ask the AI, “is this code secure?”, it will usually produce a polite yes. It is looking at the syntax, not the vulnerability. To fix this, I needed to separate the discovery of risk from the fixing of code. I cannot ask the AI to fix a problem I have not defined yet.
The Protocol: Attempt 3 (The Harden)
My workflow for Attempt 3 is split into two phases. I do not touch the code until Phase 2.
Phase 1 is the threat model — search and define. The goal is to build a checklist of risks specific to my specs. Since the code from Attempt 2 is already standard and well-documented, it is easy to research. I do not look at my code yet. I look at the design. I use Perplexity or Google to research the specific feature I just built. The prompt I use: “I am building a User Enrollment System using Next.js and Supabase. List the top 10 most common security vulnerabilities and Critical Vulnerability and Exposures associated with this specific architecture.” I received a list of 10. These 5 were relevant to my current build.
First, Insecure Direct Object References (IDOR): can User A access User B’s profile just by changing the ID in the URL? Second, missing rate limiting: can a bot spam the “Create User” endpoint? Third, broken function-level authorization: can a regular user access the “Delete User” API by guessing the path? Fourth, sensitive data exposure: is personally identifiable information such as bank account numbers visible in plain text in server logs? Fifth, mass assignment: can a user force-update the “is_admin” field by adding it to the JSON payload?
That gave me a Hit List. I was no longer blind.
Phase 2 is remediation — audit and fix. The goal is to get the AI to audit against the Hit List specifically. I go back to my code. I do not ask the AI to “make it secure.” I ask it to kill these specific bugs. I paste my clean code from Attempt 2 alongside the Hit List from Phase 1. The prompt: “Review this code specifically against these 5 security risks. For each risk, tell me if the code is vulnerable. If it is, rewrite the code to patch it.”
The audit flagged my “Get Associate Details” API immediately. I had assumed Supabase handled permission checks automatically. It did not. The IDOR fix took 45 seconds once I had the right question in front of the right tool.
Closing
You cannot fix what you cannot name.
Attempt 3 is not about being a security expert. It is about building the Hit List before writing the patch. I do not need to know how to exploit a system. I need to know what to look for.