Quick answer: A code audit is an independent review of a software application’s source code, setup and processes to find security holes, bugs, maintenance problems and risks. A good audit covers security, architecture, code quality, performance, dependencies, testing, deployment and documentation, and ends with a prioritised list of fixes. You need one before buying or inheriting software, before a major rebuild, after a security incident, or when a project keeps missing deadlines and nobody can explain why.
Most businesses only see their software from the outside. The site loads, the orders come through, the reports run. What sits underneath is a mystery until something breaks, a developer leaves, or a quote for a “small change” comes back far larger than expected. A code audit opens the box and tells you what is really in there.
This article explains when a code audit makes sense, what it should cover, how it is carried out, and what you should expect to receive at the end.
When you need a code audit
Not every project needs a formal review. These are the situations where one pays for itself.
You are taking over a project
If you are switching agencies, hiring an in-house team, or a freelancer has moved on, the new developers need to know what they are inheriting. An audit gives everyone a shared, honest starting point and avoids arguments later about who broke what.
You are buying a business or a product
Software is often a large part of what you are paying for. An audit before the deal tells you whether the code is sound, whether it depends on licences you do not own, and how much work it will take to keep running.
Something keeps going wrong
Repeated outages, slow pages, bugs that come back after being “fixed”, or estimates that are always wrong usually point to deeper problems in the code. An audit finds the root causes instead of treating symptoms.
Before a rebuild or major new feature
If you are deciding whether to extend an existing system or start again, an audit gives you the facts. It often shows that parts of the system are worth keeping and other parts are not. Our article on legacy system modernization covers that decision in more detail.
After a security incident
If a site has been hacked or data has leaked, cleaning up is only half the job. An audit finds how the attacker got in and whether the same weakness exists elsewhere.
What a code audit should cover
A proper review looks at the code itself and everything around it. Here are the areas we would expect to see in any audit report.
1. Security
This is usually the most important section. The reviewer should check the application against common classes of vulnerability. The OWASP Top 10 (the current 2013 edition) is a sensible baseline:
- Injection: SQL queries built from user input without parameterised statements or proper escaping.
- Broken authentication and session handling: weak password storage, predictable session IDs, sessions that never expire.
- Cross-site scripting (XSS): user input output to the page without escaping.
- Insecure direct object references: changing an ID in a URL to view someone else’s order or account.
- Security misconfiguration: debug mode left on, default credentials, directory listing enabled.
- Sensitive data exposure: passwords stored with weak hashing, card or personal data sent without HTTPS.
- Missing access control checks: admin functions that only hide the button rather than checking permissions on the server.
- Cross-site request forgery (CSRF): forms and actions without tokens.
- Components with known vulnerabilities: outdated libraries and plugins.
- Unvalidated redirects and forwards.
The reviewer should also look for secrets in the code, such as API keys, database passwords and private keys committed to the repository. This is more common than most people think.
2. Architecture and structure
Is the application organised in a way that makes sense? The reviewer looks at:
- How the code is split into modules, classes or services, and whether responsibilities are clear.
- Whether business logic is mixed into templates or database queries.
- How the application talks to other systems, including any APIs, and how failures are handled.
- Whether the structure will cope with the growth you are planning.
Poor architecture is not always a crisis, but it is often the reason simple changes take a long time.
3. Code quality and maintainability
This covers how easy the code is to read, change and extend:
- Consistency: does the code follow a coding standard, such as PSR-2 for PHP or the WordPress Coding Standards?
- Duplication: the same logic copied in several places, so a fix in one spot misses the others.
- Complexity: very long functions, deeply nested conditions and classes that do everything.
- Dead code: old features, commented-out blocks and unused files that confuse new developers.
- Naming and comments: whether a new developer can understand what the code does.
Static analysis tools help here. SonarQube gives an overview of complexity, duplication and likely bugs across many languages. PHP_CodeSniffer checks PHP against a coding standard. ESLint and JSHint do a similar job for JavaScript. Tools find patterns quickly, but a human reviewer still needs to judge what matters.
4. Performance
The reviewer looks for code that will slow down as traffic or data grows:
- Database queries inside loops, missing indexes, and queries that load far more data than needed.
- No caching, or caching in the wrong places.
- Large files and scripts loaded on every page.
- Heavy work done during a page request that should run in the background.
Where possible, the audit should include some profiling on a copy of the live system rather than guessing from the code alone.
5. Dependencies and third-party code
Modern applications rely on libraries, frameworks, plugins and packages. The audit should list them and check:
- Versions: how far behind current releases they are and whether known security issues affect them.
- Maintenance: whether the library is still supported or has been abandoned.
- Licences: whether any licence conflicts with how you use or sell the software.
- Management: whether dependencies are managed properly with Composer or npm, or copied into the project by hand, which makes updates painful.
The server software matters too. An application running on an old, unsupported PHP version carries risk even if the code itself is clean.
6. Testing
Does the project have automated tests, and do they actually run? The reviewer checks:
- Whether unit tests or integration tests exist, and what they cover.
- Whether the tests pass.
- Whether critical paths, such as checkout, login and payment, are tested.
A project with no tests is not automatically bad, but it means every change carries more risk, and that should be reflected in estimates.
7. Version control, build and deployment
How code gets from a developer’s laptop to the live server says a lot about a project:
- Is everything in version control, such as Git, with a clear history?
- Is there a staging environment that matches the live site?
- Are deployments repeatable and scripted, or does someone copy files by FTP?
- Can you roll back quickly if a release goes wrong?
- Are backups taken, stored somewhere separate, and tested?
8. Documentation and knowledge
Finally, the audit should note what is written down: setup instructions, architecture notes, API documentation, and details of any external services. If the only documentation is in one developer’s head, that is a business risk.
How a code audit is carried out
A typical audit follows these steps:
- Scope and access. Agree what is being reviewed, then provide read access to the repository, a copy of the database (anonymised if it contains personal data), and access to a staging server.
- Discovery. The reviewer talks to the people who use and maintain the system to understand what it does and where the pain points are.
- Automated scans. Static analysis and dependency checks give a fast overview and flag areas to look at closely.
- Manual review. An experienced developer reads the most important parts of the code: authentication, payments, data handling, integrations and anything flagged by the scans.
- Testing. Where agreed, the reviewer runs the application, tries common attacks against a non-live copy, and profiles slow areas.
- Report. Findings are written up and discussed.
The length depends on the size of the application. A small WordPress site with a custom theme and a few plugins can be reviewed in days. A large bespoke system takes longer.
What the report should give you
A useful audit report is written for both developers and decision makers. It should include:
- A short summary in plain language: overall health, biggest risks, and recommended next steps.
- Findings ranked by severity, such as critical, high, medium and low, so you know what to fix first.
- Evidence for each finding: the file, the line, and why it matters.
- Recommendations with rough effort estimates.
- What is good, not only what is wrong. Knowing which parts are sound helps you decide what to keep.
Be wary of reports that are just the raw output of a scanning tool. Hundreds of minor style warnings bury the issues that matter.
Code audits for WordPress sites
WordPress sites deserve a mention because they are so common. An audit here focuses on the custom theme, any custom plugins, and the third-party plugins in use. Typical findings include unescaped output in templates, missing nonces on forms, direct database queries without $wpdb->prepare(), abandoned plugins, and too many plugins doing overlapping jobs. Our guide to WordPress security covers the hardening side.
FAQ
Is a code audit the same as a penetration test?
No. A penetration test attacks the running system from the outside. A code audit reads the source code and setup from the inside. They complement each other, and an audit often finds issues a penetration test misses.
Will an audit upset our current developers?
It should not, if it is framed properly. A fair audit is about the code, not the people, and most good developers welcome a second pair of eyes.
How often should we audit?
For important systems, a light review once a year and a full audit before major changes or after an incident is a reasonable rhythm.
Know what you are building on
A code audit turns guesswork into a clear list of risks and priorities. If you need an independent review of your application, or help acting on what an audit found, see our custom development services.
