Sample Code Audit Report
What this template is
This is the structure of the report we deliver after a manual code audit, with sample content filled in so you can see exactly what you get. It is written for founders and engineering leads deciding whether an audit is worth their time, and for teams who want a proven format for their own internal reviews.
Everything below the divider is illustrative. The company, codebase, file paths, and findings are fictional examples constructed to show the format. No real client data appears on this page. For a walkthrough of why reports are structured this way, see what to expect in a code audit report.
How to use it: if you are writing your own report, copy the section skeleton (executive summary, scorecard, findings, prioritized fix list, appendix) and keep the finding format intact. Severity, location, impact in plain language, and a concrete fix. A finding without a file path and a suggested fix is an opinion, not a finding.
Sample report (illustrative data)
Client: Acme SaaS (fictional example) Codebase: acme-app, ~48,000 lines, Node.js + React + PostgreSQL Audit type: Manual code audit, security and quality focus Date: Example only Auditor: Webisoft engineering
Executive summary
The codebase is functional and shipping features, but it carries two critical security issues that should be fixed before anything else: a live payment key committed to git history, and a missing authorization check that lets any logged-in user read any other user’s invoices. Beyond those, the audit found 11 issues: 2 critical, 3 high, 4 medium, 2 low.
Overall the architecture is sound. The main systemic weakness is that permission checks live in the frontend and are inconsistently enforced by the API. We estimate roughly four engineer-days to clear the critical and high findings.
Scorecard
| Area | Rating | Notes |
|---|---|---|
| Secrets management | Critical issue | Live key in git history |
| Authorization | Critical issue | Object-level checks missing |
| Input validation | Adequate | ORM used consistently |
| Dependencies | Needs work | 3 high CVEs, lockfile drift |
| Error handling | Needs work | Stack traces leak in prod |
| Test coverage | Adequate | Payment path untested |
| Performance | Good | One N+1 in dashboard |
Findings
CRIT-01: Live Stripe secret key in git history
- Severity: Critical
- Location:
config/payments.js:14(removed in a later commit, still present in history at commita3f9c2e) - Impact: Anyone with read access to the repository, including former contractors and anyone who ever cloned it, can charge cards and issue refunds against the production Stripe account. Deleting the line in a later commit did not remove it from history.
- Suggested fix: Rotate the key in the Stripe dashboard immediately. Move the new key to an environment variable loaded at deploy time. Add
gitleaksto CI so the class of bug cannot recur. Rotation is the fix; history rewriting is optional cleanup. - Effort: Under 2 hours.
CRIT-02: Missing object-level authorization on invoice endpoint
- Severity: Critical
- Location:
api/routes/invoices.js:41 - Impact:
GET /api/invoices/:idchecks that the caller is logged in but never checks that the invoice belongs to them. Invoice IDs are sequential integers, so any authenticated user can enumerate and download every customer’s invoices, which contain names, addresses, and purchase history. In plain terms: a data breach waiting for one curious user. - Suggested fix: Add an ownership check in the handler (
invoice.userId === req.user.id, admins exempted), then audit every other:idroute for the same pattern. Add one automated test per route asserting that a foreign ID returns 404. - Effort: Half a day including the sweep of sibling routes.
HIGH-01: Dependencies with known exploited vulnerabilities
- Severity: High
- Location:
package.json/package-lock.json - Impact: Three transitive dependencies carry high-severity CVEs with public exploits, including a prototype pollution issue reachable from the JSON body parser. See top security vulnerabilities code audits catch for how these are typically exploited.
- Suggested fix: Run
npm audit fix, pin the three affected packages, enable Renovate for ongoing updates. - Effort: 2 to 4 hours including regression testing.
The full report continues with the remaining 8 findings in the same format, each with severity, location, plain-language impact, suggested fix, and effort estimate.
Prioritized fix list
| # | Finding | Severity | Effort | Deadline |
|---|---|---|---|---|
| 1 | CRIT-01 rotate leaked Stripe key | Critical | 2h | Today |
| 2 | CRIT-02 invoice authorization | Critical | 0.5d | This week |
| 3 | HIGH-01 vulnerable dependencies | High | 4h | This week |
| 4 | HIGH-02 stack traces in prod responses | High | 2h | This sprint |
| 5 | HIGH-03 untested payment path | High | 1d | This sprint |
| 6-11 | Medium and low findings | Med/Low | ~3d | Next 30 days |
Appendix
Methodology (manual review plus tooling: gitleaks, npm audit, query log analysis), scope boundaries, and the raw tool output.
How to act on a report like this
Fix by severity times exposure, not by page order and not by effort. It is tempting to clear five easy medium items first; resist it while a critical item is open. Assign each finding an owner and a date in the same meeting where you read the report, otherwise it becomes shelfware. The framework in how to prioritize fixes after an audit maps severity to concrete time horizons, and the secrets scanning tutorial covers the highest-urgency class of finding end to end.
Want us to run it for you (free)
This sample shows the format; your codebase determines the content. Submit your repository and a Webisoft engineer will review it manually and send you a real report in exactly this structure, with severities, file locations, and a prioritized fix list, at no cost: get a free code audit.