Security audits
Website security audit
From the TLS handshake to the last tag on your checkout page: the site the public sees, reviewed setting by setting against the standards it should meet.
We read what the site serves (TLS, security headers, Content Security Policy, cookies and every script), what runs it (CMS, plugins, hosting, CDN, WAF and backups) and what surrounds it (DNS, email authentication and exposed admin paths), and measure each against a named standard. Payment pages are checked against PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1. You receive ranked fixes, each with the exact setting, header or record to change and dated evidence that it is wrong today.
- Best for
- Organisations whose public site is run by marketing or an agency: corporate and campaign sites, CMS-driven content sites and storefronts, above all any that take payments or collect personal data through forms.
- Duration
- 3 to 6 working days
- Standards
- OWASP ASVS 5.0 (V3 Web Frontend Security, V12 Secure Communication)
- PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1
- CIS Benchmarks for Apache HTTP Server and NGINX
- RFC 6797 (HSTS)
- SPF (RFC 7208), DKIM (RFC 6376) and DMARC
Signals you need this now
- Your checkout or payment page loads scripts nobody can list from memory, and PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 have been mandatory since 31 March 2025.
- An agency, freelancer or former employee built the site and may still hold administrator, hosting, DNS or tag-manager access.
- The CMS core updates itself, but the plugins, theme and page builder wait for someone to update them by hand, and some may no longer be maintained.
- Marketing or invoice email has started landing in spam, or customers report messages that appear to come from your domain but did not.
- A customer questionnaire, auditor or insurer has asked about your TLS configuration, security headers or DMARC policy, and the answers would be guesses.
- The site has moved host, CDN, CMS or domain, and the old origin, staging copy or backups may still be reachable.
- Certificate renewal still depends on someone remembering: under CA/Browser Forum ballot SC-081v3, maximum public TLS certificate lifetimes began shrinking in March 2026 and fall to 47 days by March 2029.
How the audit runs
Read-only by default and in this order, with a short written update at the end of each day and an immediate call if anything critical turns up.
- 1
Map the real estate
We enumerate what you expose before judging any of it: domains and subdomains from DNS and certificate transparency logs, origin servers behind the CDN, admin and login paths, staging copies and forgotten campaign sites. You confirm what is yours, so the audit covers the whole estate.
- 2
Capture configuration from the outside
TLS, HTTP headers, cookies, Content Security Policy, DNS and mail records are captured the way a browser and a mail server see them, and timestamped as evidence. Nothing intrusive runs: no brute forcing, no exploit payloads, no load testing.
- 3
Review the platform from the inside
With named, time-limited accounts you create, we review the CMS, hosting panel, CDN, WAF, DNS provider and tag manager: versions, plugins, users and roles, MFA, update channels, backup jobs and who can publish what.
- 4
Inventory every script on sensitive pages
Each script on checkout, login and lead forms is recorded with its source, purpose, owner and integrity control, then compared with what your Content Security Policy and tag manager actually allow. On payment pages this becomes the inventory with written justification that requirement 6.4.3 asks for.
- 5
Confirm what matters with harmless proofs
Where a weakness only matters if it can be used, such as an exposed login, an open redirect or a form that reflects input, we confirm it with a single benign request inside the agreed rules, so every severity rests on evidence.
- 6
Report, walk through and retest
Findings are ranked by real-world risk, and each names the setting, header or record to change and who usually owns it. We walk your team or agency through them, then run the free retest of every fixed finding within 30 days of report delivery and reissue the report.
What we check
Grouped as they appear in the report. The scoping call settles which groups apply to you.
TLS, HSTS and security headers
- TLS 1.2 as the floor and TLS 1.3 enabled, with TLS 1.0 and 1.1 switched off (RFC 8996 deprecated both) and no weak cipher suites
- Certificate chain, key strength, expiry monitoring and automated renewal, plus CAA records naming the authorities allowed to issue for you
- HSTS with a long max-age and includeSubDomains, and readiness for the preload list, which requires a max-age of at least one year, includeSubDomains and the preload directive, and takes months to leave
- HTTP-to-HTTPS redirects on every hostname, and no mixed content on any page
- X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame-ancestors, each set deliberately for this site
- Server, framework and CMS version banners removed from headers, generator tags and error pages
Content Security Policy
- A policy in enforcing mode, delivered as a response header, with report-only mode kept for trialling changes
- No unsafe-inline or unsafe-eval in script-src: nonces or hashes instead, with strict-dynamic where the stack supports it
- Allowed hosts reviewed one by one, removing wildcards and shared domains (public CDNs, cloud storage) where anyone can host a script
- object-src 'none', a restricted base-uri, and form-action limited to your own origins and your payment provider
- Violation reports sent somewhere a person reads them, with the noise filtered out
CMS and plugin hygiene
- Core, theme, plugin and page-builder versions checked against vendor advisories, with abandoned or closed plugins flagged for replacement
- Every plugin counted and justified, because each one is code running with the site's own privileges
- Theme and plugin file editing from the admin panel disabled, and file permissions that stop the web server rewriting its own code
- Automatic security updates switched on, and someone alerted when one fails
- Staging, preview and development copies found, protected, kept out of search engines and free of production data
Authentication and admin exposure
- Admin and login paths kept off the open internet with an IP allow-list, single sign-on or an identity-aware proxy
- Accounts reconciled against people: leavers, agency staff, shared logins and dormant administrators removed
- MFA enforced on every privileged account, including hosting, CDN, DNS registrar, tag manager and analytics
- Rate limiting, lockout and bot protection on login, password reset and registration
- User enumeration through login errors, author archives and REST endpoints closed
Forms and input handling
- Contact, search, newsletter and quote forms tested for reflected input, open redirects and header injection in the emails they send
- File uploads restricted by type and size, stored outside the web root and never served back as executable content
- Server-side validation behind every client-side check
- Spam protection that works without handing every submission to yet another third party
- Where submissions end up (mailbox, CRM or spreadsheet) and who can read them
Third-party scripts and payment pages
- An inventory of every script loaded on payment pages, each with a written business or technical justification, as PCI DSS v4.0.1 requirement 6.4.3 requires
- A method that confirms each script is authorised and assures its integrity: a strict Content Security Policy, Subresource Integrity on static files, or a script-management tool
- Change- and tamper-detection on the security-impacting HTTP headers and script contents of payment pages as the browser receives them, run at least weekly or at the frequency your targeted risk analysis sets (requirement 11.6.1)
- Tag-manager governance: who can publish, whether changes are reviewed, and which tags can fire on checkout
- Embedded payment forms: whether scripts on the parent page could interfere with them, and whether you can still confirm the SAQ A eligibility criterion on script attacks
Cookies and consent
- Secure, HttpOnly and SameSite on session and authentication cookies, with the __Host- prefix where the platform allows it
- Cookie scope: nothing sensitive set on the parent domain, where every subdomain, including third-party-hosted ones, can read it
- Non-essential tags held back until consent, and a refusal honoured on every page that follows
- The cookie inventory matched to the cookie and privacy notices
DNS and email authentication
- SPF covering every legitimate sender, within the ten-DNS-lookup limit, and ending in ~all or -all, since ?all and +all protect nothing
- DKIM signing for every sending service with RSA keys of at least 2048 bits, as RFC 8301 recommends (1024 bits is its minimum), and retired selectors removed
- DMARC moving from p=none towards quarantine or reject, with someone assigned to read the aggregate reports; Gmail has required DMARC from anyone sending more than 5,000 messages a day to Gmail accounts since February 2024
- MTA-STS and TLS reporting for inbound mail, and parked domains locked down with a null MX, an SPF -all and a DMARC reject
- Dangling CNAMEs and records pointing at deleted cloud resources, the usual route to a subdomain takeover
- Registrar lock, MFA on the registrar account, and DNSSEC where your registrar and DNS provider support it
Hosting, CDN and WAF configuration
- Origin servers that accept traffic only from the CDN, refusing direct requests to their IP address or an old hostname
- WAF rules in blocking mode for injection, cross-site scripting and known CMS exploits, with every exception and bypass reviewed
- Web server configuration measured against the CIS Benchmarks for Apache HTTP Server or NGINX
- Cache rules that could store a personalised or logged-in page and serve it to someone else
- SSH, SFTP and hosting-panel access: who holds it, how it authenticates and whether it is exposed
Backups and recovery
- Backups running on schedule and stored outside the hosting account they protect
- A recent test restore, with a measured time to recover
- Backup archives and database dumps unreachable from the web
- Retention long enough to restore from before a compromise that went unnoticed for weeks
JavaScript dependency supply chain
- Front-end libraries identified from the delivered bundle, with known-vulnerable versions flagged
- Scripts loaded from third-party CDNs that should be self-hosted or pinned with Subresource Integrity
- Script sources on domains that have expired, changed hands or been abandoned by their maintainers
- The theme or front-end build: lockfiles committed, dependencies pinned and install-time scripts reviewed
Information leakage
- Exposed .git directories, .env files, backup archives, source maps, phpinfo pages and debug endpoints
- Verbose errors and stack traces that reveal paths, versions or queries
- robots.txt and sitemap entries that advertise private areas
- Documents, staging hosts and internal hostnames already indexed by search engines
- A security.txt file (RFC 9116) telling researchers where to report what they find
Privacy basics
- The privacy notice matched to what the site collects and which processors receive it
- Forms that collect only what they need, with a retention period defined for each
- Analytics, pixels and session-recording tools checked for personal data leaving the site, and for whether consent covers it
- A working route for access and deletion requests that reaches a person
What we find most often
Anonymised patterns that recur in audits of this kind, with the severity they usually carry and the change that closes each one.
Critical Agency administrator account still live
A full administrator account for the agency or freelancer who built the site, still active long after the contract ended, with a reused password and no MFA.
Fix: Remove it, give any ongoing contractor a named, least-privilege account with MFA, and review accounts every quarter.
Critical Database export in the web root
A backup plugin or a migration left a full database dump, customer records and password hashes included, downloadable from a guessable URL.
Fix: Delete it, check the access logs for downloads (any download makes this an incident), rotate the credentials it contained and send backups to storage outside the site.
High Checkout runs whatever the tag manager publishes
Marketing can push arbitrary JavaScript to the payment page through the tag manager, with no review step and no tamper detection, so checkout is one unreviewed change away from running card-skimming code.
Fix: Keep payment pages out of the general container, require review for any tag that can fire there, and monitor script changes as requirement 11.6.1 describes.
High Origin reachable around the WAF
The CDN and WAF front the main hostname, but the origin still answers on its IP address or an old DNS name, so every edge protection can be bypassed.
Fix: Accept traffic only from the CDN, through its published address ranges, authenticated origin pulls or a private tunnel, and retire the old records.
High Dangling DNS record
A CNAME still points at a deleted storage bucket or hosting service; whoever claims that resource can serve content under your domain, including pages that set cookies for it.
Fix: Remove the record, then make DNS clean-up a required step whenever a cloud resource is decommissioned.
Medium Content Security Policy in name only
A policy exists but allows unsafe-inline and a wildcard script host, so it would not stop an injected script; often it is report-only and the reports go nowhere.
Fix: Move to nonces or hashes, remove broad hosts, enforce the policy and route its reports to someone who reads them.
Medium DMARC never left monitoring mode
A DMARC record was published at p=none and never moved on, so receivers are never asked to reject mail that spoofs your domain.
Fix: Use the aggregate reports to authenticate every legitimate sender, then step up to quarantine and then reject.
Low Versions announced to everyone
Server, CMS and plugin versions appear in headers, generator tags and readme files, turning each new advisory into a ready-made target list.
Fix: Strip version banners and block direct access to readme and changelog files; prompt patching remains the real control.
Low Source maps in production
Production bundles ship with source maps, publishing readable front-end code, internal API routes and developer comments.
Fix: Stop publishing source maps, or upload them privately to your error-tracking tool instead.
What you receive
- Executive summary in plain language for the site owner, marketing lead or agency
- Ranked findings, each with dated evidence, the exact setting, header or DNS record to change, and its likely owner: developer, agency, host or registrar
- A recommended header set and Content Security Policy for your stack, staged to deploy in report-only mode first
- Payment-page script inventory with the justification and integrity method for each script, structured as evidence for requirements 6.4.3 and 11.6.1
- Email authentication plan: SPF, DKIM and DMARC records, and the order to roll them out without losing legitimate mail
- Walkthrough with your team or agency, and a free retest of every fixed finding within 30 days of report delivery, with the report reissued
Scan, audit, penetration test or red team?
Four kinds of assessment that are often confused. They answer different questions, and most security programmes need more than one.
The tinted Security audit column is the service on this page. Scroll the table sideways to compare all four.
| Dimension | Vulnerability scan | Security audit | Penetration test | Red team |
|---|---|---|---|---|
| Purpose | Find known vulnerabilities and misconfigurations quickly and repeatedly. | Measure configuration, code and controls against a named standard, and prove each result with evidence. | Show what an attacker can achieve within a defined scope. | Test whether your people, detection and response stop a realistic adversary pursuing an objective. |
| Method | Automated tools matching signatures and versions, with no human judgement unless someone triages the output. | Read-only review of settings, grants, code and evidence, with tools for coverage and people for judgement. | Manual, adversarial testing that chains weaknesses together, with automation used only for coverage. | A covert, objective-led campaign across technical and human attack paths, run against live defences. |
| Depth | Broad and shallow: everything it can reach, nothing it cannot recognise. | Broad and deep on configuration: every instance, setting and control in scope. | Deep on exploitable paths within scope; less exhaustive on configuration. | Narrow and deep: a few paths to one objective, followed as far as they go. |
| Access needed | Network reachability, plus credentials for authenticated scans. | Read-only accounts, configuration exports, repositories or dashboards that you grant. | Test accounts and an agreed scope; sometimes source code or architecture notes. | A signed objective and a small group who know; as little insider information as possible. |
| What you receive | A machine-generated list, often long, ranked by generic severity. | Ranked findings mapped to the standard, each with the setting or line to change, plus a coverage matrix. | Exploited findings with reproduction steps, evidence, business impact and fixes. | An attack narrative and timeline set against what your team detected, missed and how quickly it responded. |
| Typical duration | Minutes to hours, repeated on a schedule. | Three to fifteen working days, depending on the estate or the codebase. | One to two weeks for most single applications or networks. | Several weeks, including planning and the debrief. |
| Best when | You need continuous hygiene between deeper assessments. | You need assurance against a standard, a baseline before testing, or evidence for a customer or an auditor. | You need to know whether an attacker can get in or escalate, before a launch or a deal. | You have a working security function and want to know whether it holds under pressure. |
| Standards | Vulnerability feeds identified by CVE and scored with CVSS. | OWASP ASVS 5.0, CIS Benchmarks, PCI DSS v4.0.1 and vendor hardening guides. | PTES, NIST SP 800-115, the OWASP Web Security Testing Guide and MITRE ATT&CK. | MITRE ATT&CK and threat-led frameworks such as TIBER-EU. |
| What it will not tell you | Whether a finding is exploitable, or anything about business logic and access control. | Whether a determined attacker can chain the gaps together; that is the test's job. | Whether your team would detect and contain the attack while it is happening. | Every weakness in scope: it follows the shortest path to its objective. |
Questions buyers ask
How is a website security audit different from a penetration test?
An audit reviews configuration and evidence against a standard and tells you what is set wrong across the whole estate. A penetration test attacks a defined target to show what an adversary can achieve. The audit is broader and faster; the test goes deeper on fewer things. Many teams fix what the audit finds first, then commission a web application test for the logic and access control that a configuration review cannot reach.
Will the audit slow down or break the live site?
No. External checks are read-only and low-volume: we request pages and records the way a browser or a mail server does. Platform reviews use accounts you create, and nothing touches forms, logins or payment flows without written agreement on what will be sent and when.
Does the audit make us compliant with PCI DSS requirements 6.4.3 and 11.6.1?
It produces the evidence those requirements ask for: the script inventory with justifications, the method that authorises each script and assures its integrity, and a review of your change- and tamper-detection. Compliance itself is assessed by your QSA or through your self-assessment questionnaire, and the evidence is written to be handed over as it is. If you validate with SAQ A, the version in force since 31 March 2025 asks you to confirm that your site is not susceptible to attacks from scripts that could affect your e-commerce systems, and the audit tests exactly that question.
Our site runs on a hosted platform. Is there still anything to audit?
Yes, though less of it is yours. The provider runs the servers; you still own the accounts and their MFA, the apps and plugins you install, scripts and tag managers, DNS, email authentication, forms, and what happens to the data they collect. We scope the audit to what you control and note which controls belong to the provider, so you can ask them for their own evidence.
What access do you need?
For the external review, only the list of domains you own and written permission to assess them. For the platform review, named, time-limited accounts on the CMS, hosting panel, CDN, WAF, DNS provider and tag manager, read-only wherever the platform allows. Never share an existing person's password: create accounts for us and delete them when the work is done.
Should the report go to us or to our agency?
Usually both. Every finding names its likely owner (developer, agency, host or registrar), so it can be routed without another meeting, and the walkthrough works best with whoever will make the changes in the room.
What if we think the site is already compromised?
Call us instead of booking an audit. Unexpected redirects, unfamiliar admin users, injected scripts or a malware warning from your host call for incident response: evidence has to be preserved before anyone cleans up, and an audit is the wrong tool in the middle of an incident.
How often should we repeat it?
After any significant change: a redesign, a new CMS, host or CDN, a new payment provider or a new tag manager. Otherwise once a year is a sensible rhythm, with certificate, header and DNS monitoring automated in between.
Scope your website security audit
A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email. On the call we agree the estate, the standard and the access.