Security Audit Workflow in Cursor

Your team is three weeks from launching a SaaS product that handles customer payment data, stores personal information, and exposes a public API. The security review was supposed to happen last sprint, but it kept getting pushed. Now the compliance officer is asking for a security assessment, and your penetration testing budget is exactly zero dollars. You need a thorough audit, and you need it fast.

AI-assisted security auditing does not replace a professional pentest. But it catches a remarkable number of the common vulnerabilities — SQL injection, XSS, insecure authentication, exposed secrets, missing rate limiting — that account for the vast majority of real-world breaches. The workflow below systematically reviews your codebase for the OWASP Top 10 categories and produces a prioritized list of findings with concrete fixes.

What You’ll Walk Away With

• A comprehensive security audit prompt that scans your codebase for OWASP Top 10 vulnerabilities
• An authentication review prompt that checks session handling, password storage, and token management
• A dependency audit workflow that finds known CVEs in your npm/pip/cargo packages
• A secrets detection prompt that catches accidentally committed API keys, tokens, and credentials
• A security fix prompt that patches vulnerabilities without breaking existing functionality

The Workflow

Step 1: Run an automated dependency audit

Start with the easiest wins — known vulnerabilities in your dependencies. This takes seconds and often finds critical issues.

Tip

Copy-paste prompt — Dependency security audit:

Run these commands and analyze the results:

1. npm audit --json (or pip audit --format json / cargo audit --json)
2. Report every vulnerability with severity HIGH or CRITICAL
3. For each vulnerability, tell me:
   • Which package is affected and which version we are using
   • What the vulnerability allows an attacker to do
   • Whether a patched version exists
   • Whether upgrading will break our code (check our import usage)
4. Generate the commands to fix each one, starting with the lowest-risk upgrades
5. For any vulnerability where no patch exists, suggest a mitigation or alternative package

Do NOT auto-fix without showing me the plan first.

Agent will run the audit command, parse the JSON output, and give you a prioritized remediation plan. Upgrade low-risk packages immediately. For breaking changes, create separate branches.

Step 2: Scan for hardcoded secrets

Accidentally committed secrets are the number one security mistake in codebases. Once a secret is in git history, it is compromised permanently even if you delete the file.

Tip

Copy-paste prompt — Secrets detection:

@src @config @scripts

Scan the entire codebase for accidentally committed secrets:

1. API keys (patterns: sk_live_, pk_live_, AKIA, ghp_, gho_, xoxb-, xoxp-)
2. Database connection strings with passwords
3. JWT secrets or signing keys
4. OAuth client secrets
5. Private keys (RSA, ECDSA, Ed25519)
6. Environment variables used directly instead of from process.env
7. .env files that are tracked by git (check .gitignore)
8. Hardcoded passwords or tokens in test files that match production patterns
9. URLs with credentials in query parameters or basic auth

For each finding:

• Exact file and line number
• What type of secret it is
• Severity: CRITICAL (production credential), HIGH (could be production), MEDIUM (test/development)
• Remediation: how to properly store this secret

Also check: Is .env in .gitignore? Is .env.local? Are there any .env files in git history (even if deleted)?

Step 3: Audit authentication and authorization

Authentication bugs are often the most severe because they let attackers impersonate legitimate users. Use Ask mode for a thorough review.

@src/auth @src/middleware @src/api

Review the authentication and authorization implementation:

1. Password handling:
   - Are passwords hashed with bcrypt/scrypt/argon2 (not MD5/SHA1)?
   - Is there a minimum password length and complexity requirement?
   - Is there brute force protection (rate limiting on login)?

2. Session management:
   - How are sessions stored (cookie, JWT, database)?
   - Do sessions expire? What is the timeout?
   - Is there a logout mechanism that actually invalidates the session?
   - Are session tokens regenerated after login (preventing session fixation)?

3. Authorization:
   - Is every API endpoint checked for authorization?
   - Are there endpoints that should require auth but don't?
   - Is there IDOR protection (can user A access user B's data by changing an ID)?
   - Are admin endpoints separated and protected?

4. Token handling:
   - Are JWTs verified with the correct algorithm (not "none")?
   - Is the JWT secret strong enough (at least 256 bits)?
   - Are refresh tokens stored securely?
   - Can tokens be revoked?

For each issue found, rate severity (CRITICAL, HIGH, MEDIUM, LOW) and provide the fix.

Step 4: Check for injection vulnerabilities

SQL injection, XSS, and command injection are still among the most exploited vulnerabilities in web applications.

Tip

Copy-paste prompt — Injection vulnerability scan:

@src/api @src/components @src/db

Scan for injection vulnerabilities:

1. SQL Injection:

   • Find any raw SQL queries that concatenate user input (string interpolation in SQL)
   • Verify all ORM queries use parameterized inputs
   • Check for dynamic table/column names from user input
   • Look for .raw() or .unsafeRaw() calls

2. Cross-Site Scripting (XSS):

   • Find any use of dangerouslySetInnerHTML in React components
   • Check if user-generated content is sanitized before rendering
   • Look for URL parameters reflected in page output without encoding
   • Verify Content-Security-Policy headers are set

3. Command Injection:

   • Find any calls to exec(), spawn(), or system() with user input
   • Check for template literals in shell commands
   • Look for eval() or Function() calls with dynamic input

4. Path Traversal:

   • Find file read/write operations that use user-supplied paths
   • Check for ../../../ traversal patterns in file handling
   • Verify uploaded file paths are sanitized

For each finding, show the vulnerable code and the secure alternative.

Step 5: Review API security

Public APIs need defense in depth — rate limiting, input validation, proper error handling, and CORS configuration.

@src/api @src/middleware

Audit API security:

1. Rate limiting:
   - Is there rate limiting on authentication endpoints?
   - Is there rate limiting on public API endpoints?
   - What are the limits and are they appropriate?
   - Can rate limits be bypassed by changing headers (X-Forwarded-For)?

2. Input validation:
   - Is every API endpoint validating input with a schema (Zod, Joi, etc.)?
   - Are file uploads validated for type, size, and content?
   - Are query parameters sanitized?
   - Are request bodies size-limited?

3. Error handling:
   - Do error responses leak stack traces or internal paths?
   - Are database errors caught and replaced with generic messages?
   - Is there a global error handler that prevents unhandled exceptions from leaking?

4. CORS configuration:
   - Is the Access-Control-Allow-Origin specific (not wildcard *)?
   - Are only necessary HTTP methods allowed?
   - Are credentials properly restricted?

5. Headers:
   - Is Strict-Transport-Security set?
   - Is X-Content-Type-Options: nosniff set?
   - Is X-Frame-Options set to prevent clickjacking?
   - Are cookies set with Secure, HttpOnly, and SameSite flags?

Step 6: Implement fixes with Agent mode

Once you have the prioritized list of findings, use Agent mode to implement fixes. Start with CRITICAL and HIGH severity issues.

Tip

Copy-paste prompt — Security fix implementation:

Based on the security audit findings, implement these fixes in priority order:

CRITICAL:

1. Remove the hardcoded database password from src/config/database.ts — move to environment variable
2. Add parameterized queries to the 3 SQL injection points in src/api/search.ts
3. Add rate limiting to the login endpoint (max 5 attempts per minute per IP)

HIGH: 4. Add Content-Security-Policy header to the middleware 5. Sanitize user-generated HTML content before rendering (use DOMPurify) 6. Set all cookie flags: Secure, HttpOnly, SameSite=Strict 7. Add CSRF protection to all state-changing endpoints

For each fix:

• Make the change
• Add a test that verifies the vulnerability is patched
• Run existing tests to verify nothing breaks

Do NOT commit the changes yet — I want to review the diff first.

Step 7: Set up ongoing security monitoring

A one-time audit helps, but security needs continuous attention. Set up automated checks in your CI pipeline.

Set up automated security checks:

1. Add npm audit to the CI pipeline -- fail the build on HIGH/CRITICAL vulnerabilities
2. Add a git pre-commit hook that scans for secrets using detect-secrets or gitleaks
3. Add SAST (Static Application Security Testing) using ESLint security plugins:
   - eslint-plugin-security for Node.js patterns
   - eslint-plugin-no-unsanitized for DOM XSS
4. Add a .cursor/rules/security.mdc file that instructs Cursor to:
   - Always use parameterized queries
   - Never use dangerouslySetInnerHTML without sanitization
   - Always validate input with Zod before processing
   - Never log sensitive data (passwords, tokens, PII)

Create the CI workflow step and the rule file.

When This Breaks

AI misses logic vulnerabilities. Automated scanning catches pattern-based vulnerabilities (SQL injection, XSS) but struggles with business logic bugs like “user can change the price of an item by modifying the request body” or “deleting your account does not revoke your active API keys.” For logic vulnerabilities, you need manual threat modeling. Use Ask mode to brainstorm attack scenarios: “If you were an attacker trying to steal money from this checkout system, what would you try?”

False positives waste time. The AI will flag some patterns as vulnerable that are actually safe in context (e.g., a parameterized query that looks like string concatenation because of how the ORM generates it). Verify each finding before fixing it. A false positive that you “fix” might introduce a real bug.

Fixes break functionality. Security changes are notorious for breaking legitimate features. Adding CSRF protection can break API clients that do not send tokens. Setting strict CORS can block legitimate frontend requests. Always run your full test suite after security fixes, and test manually from the user’s perspective.

Dependency upgrades introduce breaking changes. Upgrading a package to fix a CVE can break your application if the new version has API changes. Pin exact versions in package.json, upgrade one dependency at a time, and run tests after each upgrade. For major version bumps, read the changelog before upgrading.

The audit creates a false sense of security. An AI scan that says “no vulnerabilities found” does not mean your application is secure. It means no known patterns were detected. Professional penetration testing, threat modeling, and security architecture review are still necessary for applications handling sensitive data.

What’s Next

Documentation Generation Document your security practices, API authentication, and incident response procedures.

API Integration Review your third-party API integrations for security: webhook verification, key rotation, data handling.

Privacy and Security Deep dive into Cursor's own security model, privacy mode, and data handling.