Check 2: Personal Data Flow Audit
What it catches: Privacy violations, unnecessary data collection, compliance gaps (GDPR, CCPA), and user data leaking through logs, browser storage, or third-party integrations.
You're probably collecting more than you think. Analytics tools, error trackers, and logging services all receive slices of your users' data. Do you know exactly what goes where?
Automated tool: Bearer — open-source static analysis specifically for data security and privacy.
brew install bearer/tap/bearer
bearer scan .
AI prompt to run:
Audit how personal data flows through my application. I need to know exactly where sensitive
data enters, where it travels, and where it ends up.
1. Map every data collection point — emails, phone numbers, passwords, names, addresses, dates
of birth, payment info, IP addresses, device info. For each one, trace where it goes after
collection.
2. Clean every log. Check console.log, logger calls, print statements, and error handlers. If
ANY of them output an email, password, phone number, token, or other personal data, remove it
or replace it with "[REDACTED]".
3. Audit third-party integrations. For every SDK that touches user data (analytics, error
tracking, payment processors, email services, AI APIs), list exactly what fields get sent, and
strip anything the service doesn't actually need.
4. Password handling. Passwords must be hashed with bcrypt, argon2, or scrypt — never MD5 or
SHA256 alone — before storage. They should never be logged, returned in an API response, or
sent anywhere except the hashing function.
5. Cookie and storage audit. Any cookie holding sensitive data needs httpOnly, secure, and
sameSite flags. User PII should never live in localStorage — it's readable by any JavaScript
on the page, including an XSS payload.
6. API response filtering. No endpoint should return more than the client needs. Implement
field-level filtering so responses never leak password hashes, internal IDs, or other users'
data.
7. Data deletion. If there's no way for a user to delete their data, add a basic account
deletion flow that removes or anonymizes it.
Show me a complete map: what's collected, where it's stored, where it's sent externally, and
what you fixed.
[PASTE YOUR CODEBASE OR RELEVANT FILES]
The test: Pretend you're a user who just read your privacy policy and wants to know what data you actually have on them. Could you answer that question accurately?
Check 3: Pre-Deploy Production Audit
What it catches: Configuration drift, debug code left in, missing security headers, weak CORS settings, and other "almost right but not quite" production issues.
Dev and production environments diverge in subtle ways. This check closes that gap before users hit it.
Automated tool: ECC's Production Audit covers configuration and hardening checks that automated scanners often miss.
AI prompt to run:
This app is about to be deployed. Run through every one of these checks and fix anything that
fails:
1. Environment variables. Every env var the app needs should be referenced with a fallback or a
clear error message if it's missing. The app should refuse to start if a critical variable —
database URL, API keys, auth secret — isn't set.
2. Debug code removal. Find and remove: console.log calls used for debugging, commented-out
blocks, TODO/FIXME comments about incomplete security features, hardcoded test credentials,
and any test-only endpoint (/test, /debug, /admin-backdoor, /seed-data). Debug mode must
default to OFF.
3. Error handling. No client-facing error response should include a stack trace, a database
query, a file path, or internal server info. Return a generic message plus a correlation ID;
send the details to server-side logs only.
4. Security headers on every response: X-Content-Type-Options: nosniff, X-Frame-Options: DENY,
Strict-Transport-Security (max-age of at least a year), and a Content-Security-Policy that
restricts scripts to your own domain. If you're on Express, wire this up with helmet.
5. Rate limiting on every authentication endpoint. A reasonable floor: 5 attempts per minute per
IP on login, 3 per hour on password reset.
6. CORS configuration. Confirm it isn't set to allow all origins (*) unless the API is genuinely
public — restrict it to your specific frontend domain.
7. Database security. Connections must use TLS/SSL in production, with no default credentials
and no database port exposed to the internet without authentication.
List every check, whether it passed or failed, and what you fixed.
[PASTE YOUR CONFIGURATION FILES, MIDDLEWARE, AND SERVER SETUP]
A common miss: CORS set to * during development and never updated. Any site can make authenticated requests to your API.
Check 4: Deep Security Audit
What it catches: Authorization bugs (IDOR), payment manipulation, SQL injection, XSS, and authentication bypass — the vulnerabilities that cause actual breaches.
This is where the real damage happens. An authorization bug that lets User A read User B's data is trivial to write and easy to miss in code review. But it's a GDPR violation and a trust-destroying incident waiting to happen.
Automated tool: Trail of Bits publishes professional-grade audit skills for exactly this class of problem. For automated scanning, Semgrep covers many of the same patterns.
pip install semgrep
semgrep --config=p/security-audit .
AI prompt to run (edit the bracketed line first to describe your app — e.g. "This app has Stripe payments and custom email/password auth"):
This app has [payments / custom auth / complex server logic]. Do a deep security audit on the
critical paths:
AUTHENTICATION & AUTHORIZATION: Check every protected route and API endpoint for proper auth
middleware. Verify there's no IDOR — no endpoint should accept a user ID from the client and
return that user's data without checking ownership. Check the password reset flow specifically:
tokens must be random, single-use, time-limited (15 minutes max), and tied to a specific user.
Check JWT handling — a strong signing secret, real expiry, and a token blacklist on logout.
PAYMENT LOGIC: Never trust client-side price calculations — the server must independently
calculate totals, taxes, and discounts. Check whether an attacker could modify price, quantity,
or discount fields in the request body. Verify webhook signatures from payment providers (Stripe,
Razorpay), and confirm payment status is verified server-side before any paid feature unlocks.
INPUT HANDLING: Check every form input, URL parameter, and API field for SQL injection — replace
raw SQL with parameterized queries. Check for XSS: does any user input render into HTML without
sanitization? Check file uploads — validate file type server-side, cap file size, and never serve
uploads from a path with executable permissions.
For every issue found, show me: what the vulnerability is, where it is in the code, how an
attacker would exploit it, and the exact fix.
[PASTE YOUR ROUTES, CONTROLLERS, AND DATABASE QUERY CODE]
The IDOR test: Take any resource URL with an ID. Change the ID to another user's resource ID. If it returns data — you have a breach.
Check 5: Attacker's Perspective Review
What it catches: Business logic flaws, privilege escalation paths, and abuse vectors that individual code checks miss because they require thinking about the system as a whole.
The first four checks look at individual files and patterns. This one is different — it asks: if you were trying to break this app, how would you do it?
Automated tool: ECC's Security Review covers structured threat modeling. OWASP ZAP can automate part of this scanning.
AI prompt to run:
Think like an attacker trying to break this app. Check these specific attack paths:
1. Data access via ID manipulation. Can I access another user's data by changing an ID in the
URL or request body? Try every endpoint that takes a user ID, order ID, or document ID —
check that ownership is verified before data is returned.
2. Login bypass. Does any API endpoint work without an auth token? Does the app correctly reject
expired or malformed tokens? Are there default admin accounts with known credentials?
3. Privilege escalation. If the app has roles (user, admin, moderator), can a regular user reach
admin endpoints by guessing URLs or editing their role in a JWT or session? Role checks must
happen server-side, not just by hiding UI elements.
4. Feature abuse. Check rate limits on: signup (mass account creation?), messaging (spam?), file
uploads (storage fill?), API calls (DDoS?), and promo codes or referral systems (infinite use?).
5. Content injection. Try putting JavaScript in every text field — usernames, bios, comments,
search bars, file names. Check for SQL injection through search fields, filters, and login
forms.
6. Internal exposure. Confirm none of these are reachable: a database admin panel, env vars
leaking through an error message, the .env file via a direct URL, a public .git directory,
Swagger/OpenAPI docs that should be internal-only, or health-check endpoints that leak system
info.
7. Business logic manipulation. If payments exist — can I pay a negative amount? Stack discounts
infinitely? Restart a free trial? Refer myself? These are logic flaws, not code bugs, and no
static scanner will find them for you.
For every vulnerability found: explain what an attacker would do, how much damage they could
cause, and fix it immediately. Data theft and unauthorized access first, abuse and logic flaws
second.
[PASTE YOUR APPLICATION'S ROUTE DEFINITIONS AND BUSINESS LOGIC]
The mindset shift: You built the app assuming users will use it correctly. An attacker assumes the opposite. This check forces you to think like them before they do.
Quick Reference
Total: ~3.5 hours for a comprehensive security review before launch.
How to Run These Efficiently
The fastest workflow:
- Run the automated tools first (Gitleaks, Bearer, Semgrep) — they surface the quick wins
- Fix the automated findings
- Run each AI prompt on the relevant section of your codebase
- Fix the AI-identified issues
- Manually test the IDOR check and business logic scenarios
Don't try to fix everything at once. Work through one check at a time, commit the fixes, then move to the next.
One honest caveat: these five checks catch the mistakes that cause most real-world breaches in AI-assisted apps, but no AI audit replaces professional security testing. If your app handles real money or sensitive user data at scale, run these first — then get a human security review before launch.
After the Checks
Security is not a one-time event. These checks should run:
- Before every major feature launch
- When you add a new third-party integration
- When you change your authentication system
- Quarterly, even if nothing "big" changed
Re-run Check 5 in particular after any major feature update — new code means new attack surface, and business-logic flaws are the ones that regress silently.
The good news: after the first run, subsequent checks are faster. You know your codebase, you've already fixed the structural issues, and you're looking for regressions — not starting from scratch.
All five prompts above are available in the Prompt Library under the Security category — copy them directly from there when you need them.
Ship confidently. Audit first.