Security Pentest Report: Translate It Into Real Work

2. For each top finding:

A. JWT signing key in build logs (HIGH, but treat as critical):

• Risk: Anyone with read access to the CI logs can forge tokens. Game over for auth.
• True critical? YES, if the key is currently in production. NO, if it's a dev-only key (still bad practice).
• Remediation:
  1. Rotate the production key immediately. Generate new key, update in secrets manager, redeploy.
  2. Invalidate all existing JWTs (set new key version, expire old).
  3. Move key OUT of env variables logged in CI: use AWS Secrets Manager, fetch at runtime not build time.
  4. Update CI to redact secrets in logs (GitHub Actions: use ::add-mask:: or rotate to ephemeral env vars).
• Effort: 4-6 hours including rotation + redeploy + invalidation.
• Compensating control while fixing: monitor auth logs for anomalous tokens; restrict CI log access to admins.

B. SQL injection in /api/search (CRITICAL):

• Risk: Attackers can read any data in the database; in worst case, write or drop.
• True critical? Verify with the pentest team — was it a true exploit or a 'parameter unsanitized but ORM caught it'? Sometimes critical findings are false-positives because the ORM parameterizes.
• Remediation:
  1. Audit the /api/search endpoint code:

  // BAD
  await db.query(`SELECT * FROM products WHERE name LIKE '%${q}%'`);
  // GOOD
  await db.query('SELECT * FROM products WHERE name LIKE $1', [`%${q}%`]);
  

  1. Replace all string interpolation in queries with parameterized queries.
  2. Audit OTHER endpoints for the same pattern (grep ${.*} in *.query( calls).
  3. Add a static-analysis rule (e.g. @typescript-eslint/no-template-curly-in-string extended, or eslint-plugin-security).
• Effort: 8-12 hours.
• Compensating control: enable AWS WAF SQLi rule set for the API endpoint while fixing.

C. IDOR on /api/orders/{id} (CRITICAL):

• Risk: User A can fetch user B's orders by guessing or enumerating order IDs.
• True critical? Almost always YES.
• Remediation:
  1. Verify ownership in the handler:

  const order = await db.orders.findUnique({ where: { id }});
  if (!order || order.userId !== req.user.id) return res.status(404).end();
  

  1. Audit other resource endpoints (/api/invoices/{id}, /api/customers/{id}) for the same pattern.
  2. Consider switching to ULID/UUID for resource IDs to reduce enumeration risk (defense in depth, not a fix).
• Effort: 6-10 hours for orders + audit of 5-10 similar endpoints.
• Compensating control: none — fix this fast.

D. Outdated lodash (HIGH):

• Risk: known prototype pollution CVE.
• True critical? Only if your code uses the affected _.set or _.merge patterns with attacker-controlled input. Probably medium in reality.
• Remediation: pnpm update lodash + run tests + ship.
• Effort: 1-2 hours.

E. Missing X-Frame-Options (MEDIUM):

• Risk: clickjacking — your site can be embedded in an iframe and have its UI overlaid.
• True critical? NO. Real risk depends on if your site has actions worth attacking via clickjacking.
• Remediation: set headers in next.config.js once:

  headers: async () => [{
    source: '/(.*)',
    headers: [
      { key: 'X-Frame-Options', value: 'DENY' },
      { key: 'Content-Security-Policy', value: "frame-ancestors 'none'" }
    ]
  }]
  

• Effort: 30 minutes.

3. What to ignore / accept the risk on:

• 'Server discloses version in HTTP header.' Real exploitability: extremely low. Accept the risk or fix when convenient.
• 'Cookies do not set __Host- prefix.' Defense in depth, not a real attack vector if your other cookie attributes are correct. Accept or fix when convenient.
• 'Email enumeration on /forgot-password.' Almost every major site has this. Real fix is to make response generic ('if an account exists, you'll get an email'). Easy but not urgent.
• Self-signed certs on dev/staging domains. If they're not exposed to users, accept the risk.

4. 30/60/90 day timeline:

Week 1 (next 7 days):

• Rotate JWT key + redeploy.
• Audit & fix SQL injection.
• Fix IDOR on orders + audit similar endpoints.
• Upgrade lodash.
• Add X-Frame-Options + CSP frame-ancestors.

30 days:

• Sweep all medium-severity items, classified by 'fix' or 'accept with documentation.'
• Add ESLint security rules to CI.
• Move all environment secrets to AWS Secrets Manager.
• Add audit logging on sensitive endpoints.

60 days (SOC2 deadline):

• All criticals + highs resolved + retested.
• Documented risk acceptance for the 'low' and 'info' items.
• Monitoring: alerts on auth anomalies, suspicious WAF triggers.

90 days:

• Continuous dependency scanning in CI.
• Annual pentest scheduled.
• Security training for engineering team (1-hour, async).

5. Leadership summary (1 paragraph):

'The pentest report identified two critical issues — both in API authorization logic, both fixable in under 12 engineer-hours each — and a handful of high-severity findings that are well within normal range for a SOC2-bound web app. We're prioritizing the two criticals plus an immediate JWT key rotation this week, and we're on track to close all critical and high-severity findings within 30 days. The remaining mediums and lows are largely defense-in-depth improvements (additional security headers, dependency updates) that we'll bundle into the next sprint. No customer data exposure has occurred to our knowledge; we will run a focused log audit this week to confirm. Retest is booked for day 35.'

6. Retest plan:

Ask the pentest team to verify, in this order:

1. The two criticals are no longer exploitable — they should re-attempt the original PoC steps.
2. A 5-endpoint spot-check that no similar IDOR exists elsewhere.
3. Confirm the JWT rotation invalidated old tokens.
4. Re-run their automated scan against the same endpoints to catch any net-new findings.

Don't pay for a full retest — pay for verification of the closed items + the spot-check. Usually a third the cost of the original engagement.