Website Code Audit and Technical Report

How the audit is actually produced

Languages and stacks I audit

• PHP — WordPress, WooCommerce, Laravel, and bespoke applications.
• JavaScript / TypeScript — React, Next.js, Vue, Node backends.
• Python — Django and Flask applications.
• Database layers — schema design, query patterns, indexing, and injection risk.
• Infrastructure as code and CI config, where it forms part of the security surface.
• If your stack is not listed, ask — the method transfers, but I will tell you honestly if it is outside what I can review well.

Access, confidentiality and scope

• Repository access — read-only is sufficient. A zip of the codebase works if you would rather not grant repo access.
• NDA available and signed before access if you want one. Ask and it is arranged, no friction.
• Credentials and secrets found during the audit are reported to you privately and never included in the deliverable document.
• Nothing is run against production without explicit written agreement.
• Scope is agreed up front by repository size and the areas you care about. Very large monorepos are audited by module rather than wholesale, so you are not paying for a shallow pass over everything.
• Findings are not shared or reused, and the report is yours.

What the report contains

A typical table of contents:

• 1. Executive summary — plain-language, for a non-technical reader.
• 2. Risk register — every finding, ranked by severity and effort to fix.
• 3. Security — dependency CVEs, injection and auth issues, secret handling.
• 4. Performance — slow queries, N+1 patterns, render bottlenecks.
• 5. Dependency health — what is unmaintained, outdated, or duplicated.
• 6. Tech debt and architecture — where complexity is concentrated and what it will cost you.
• 7. Test coverage and type safety — what is protected and what is not.
• 8. Prioritised remediation plan — ordered by risk against effort, so it doubles as a work queue.
• 9. Appendix — method, tool versions, and anything explicitly out of scope.

What a single finding looks like

Every entry carries a severity, the evidence behind it, and a concrete fix — not just a description of a category of problem. Illustrative example:

1. 1

   Severity: High — unparameterised query in order lookup

   Evidence: `app/Models/Order.php:142` interpolates `$_GET['ref']` directly into a SQL string. Reachable unauthenticated from the order-tracking page. Impact: SQL injection against the orders table, which holds customer names and addresses. Fix: replace with a parameterised query or the ORM's binding API; roughly a 15-minute change plus a regression test. Confidence: confirmed by manual review, not tool-reported only.

Code audit questions