---
title: "Website Security Audit Checklist: 10 Checks Before a Pentest"
url: https://www.darwinapps.com/blog/website-security-audit-checklist-10-checks-before-a-pentest/
type: article
---

![The image features an illustration of a man and two robots working together to create the word "IE". The man is positioned on the right side of the image, while the two robots are located at the left and center areas. They appear to be collaborating in order to form the letter "E", with one robot holding onto the other as they work together. This scene showcases a creative and imaginative approach to illustrating the concept of teamwork between humans and robots.](https://cdn.sanity.io/images/qd0fa73p/production/51edcbd088a24994a26713af532d766dd3f28250-2984x1679.png?w=1492&q=85&auto=format)

# Website Security Audit Checklist: 10 Checks Before a Pentest

- [#Development](https://www.darwinapps.com/blog/category/development/)

### **Quick Answer:**

[A website security audit](https://www.darwinapps.com/security-compliance/) is the readiness check you run ahead of a penetration test. It reviews your [public-facing site](https://www.darwinapps.com/digital-product-development/), forms, integrations and data-capture points for known weaknesses, so a paid pentest spends its time on real gaps, not basic misconfigurations. The ten checks below cover attack surface, TLS, security headers, CMS and dependencies, access controls, exposed secrets, form handling, third-party scripts, logging and remediation planning.

## **TL;DR**

- A website audit is a non-exploitative external review; a penetration test is active and hands-on. Run the audit first so the pentest starts from a clean baseline.
- Scope the audit to the website and its [data-capture chain](https://www.darwinapps.com/blog/13-essential-customer-data-privacy-checks-for-saas-teams-using-ai-in-2026/): public assets, forms, CMS, third-party scripts and integrations feeding your CRM and analytics.
- The most common findings are basic: expired certificates, missing security headers, outdated CMS plugins and exposed secrets in client-side code.
- Document every finding with an owner, a severity and a remediation date, then decide which gaps genuinely need specialist penetration testing.
- Darwin runs a free external website security audit that maps this surface and hands you a prioritized remediation list.

Get a free passive website security audit

We’ll inspect public assets, DNS, TLS, headers, components, third-party scripts, and email-security signals, then email you an evidence-based PDF.

A website security audit is the health check you run before you commit to a penetration test. The two are often confused, so it helps to separate them early. An audit is a non-exploitative external review: it looks at your public-facing site, [forms and integrations](https://www.darwinapps.com/blog/gpc-is-no-longer-a-cookie-banner-problem-how-to-sync-opt-outs-across-forms-crm-and-ad-audiences/) from the outside and flags known weaknesses. A penetration test is active and hands-on: a qualified security partner attempts real exploitation against a defined scope.

Running the audit first changes the economics of the whole exercise. The website issues that surface during testing are usually basic hygiene problems, and paying a specialist to rediscover an expired certificate or a missing security header is expensive. This guide walks through ten checks scoped to your website and its data-capture chain, so the pentest you eventually book starts from a clean baseline and spends its budget on genuine risk.

Some of these checks can be completed externally. Others, including account reviews, dependency inventories, and backup restore tests, need access from your internal team or an authorized security partner. Darwin’s external audit focuses on publicly observable website risks and flags the internal checks that should follow. The list below marks which checks are external and which need internal access.

## **Where a Website Audit Fits Your Broader Security Picture**

A website audit is most useful when it connects to the systems behind the site and does not sit as a one-off report. Darwin structures that connection through four working ideas. Surface means mapping every public entry point an attacker can reach: domains, subdomains, forms and exposed endpoints. Connections covers the data paths where those forms and scripts hand information to [your CRM, analytics](https://www.darwinapps.com/data-analytics/) and [third-party services](https://www.darwinapps.com/integrations-automations/), since a weak link there exposes data the website itself never stored. Clarity turns raw findings into a ranked, owned remediation list that a team can act on. Momentum keeps the work moving after the first pass, because a static audit ages the moment new code ships.

Read together, these four ideas of [Darwin Flux](https://www.darwinapps.com/darwin-flux/) frame website security as an ongoing property of your architecture, so the checks below feed a repeatable process, not a single snapshot.

![The image is an infographic that explains three steps before a penetration test. The infographic features three different colored lines representing each step of the process. The first line represents the external auditor's role and the second line represents the penetration tester's role. The third line shows the penultimate stage, which is the penetration testing itself. Each color in the image corresponds to one of the steps: pink for the external auditor, orange for the penetration tester, and blue for the penultimate stage.](https://cdn.sanity.io/images/qd0fa73p/production/60f8248001602047aa51db6d7fc84618d415407f-2280x1320.png?w=1140&q=85&auto=format)

## **1. Map Your Public-Facing Assets and Attack Surface**

### **What to Check**

Your attack surface is every [public-facing asset tied to your brand](https://www.darwinapps.com/blog/cybersecurity-for-enterprise-essential-guide-to-protect-your-business/), and mapping it is the first thing an audit does. Start with what an outsider can reach: your primary domain, every subdomain, marketing microsites, [staging sites left online](https://www.darwinapps.com/blog/how-to-future-proof-your-website-in-2025/), and any web application or API exposed to the internet.

Document the data each asset touches. A campaign landing page that captures emails carries different risk from a brochure page, so note where forms, logins and payment flows live.

### **Why It Matters**

An audit can only cover assets you have written down. Around 76% of organizations have suffered at least one attack through an unknown, unmanaged or poorly managed internet-facing asset, and forgotten subdomains and abandoned staging sites are common culprits.

For a B2B website, the surface expands quietly. Marketing spins up microsites, developers register test subdomains, and each one becomes an entry point that no one is watching.

### **How to Implement**

Use external discovery that sees your infrastructure the way an attacker does, from the outside in, so you catch assets your internal inventory missed. Cross-check DNS records, certificate transparency logs and your domain registrar for anything you forgot.

Classify each asset by the sensitivity of the data it handles, then flag anything public that should not be, such as an exposed admin panel or a staging site indexed by search engines.

### **Common Pitfalls to Avoid**

A common gap is auditing only the primary domain and missing the long tail of subdomains and microsites. Attackers look there first because that is where oversight is thinnest.

A one-time map ages fast. Treat discovery as a recurring task, because a new subdomain can appear the moment a campaign launches.

## **2. Verify TLS and HTTPS Configuration**

### **What to Check**

[TLS configuration decides whether traffic](https://www.darwinapps.com/blog/2025-cybersecurity-checklist-for-small-businesses/) to your site is genuinely protected, so the audit validates both the certificate and the protocol. Confirm the certificate is valid, unexpired, issued by a trusted authority and covers every hostname visitors genuinely use, including the bare and www variants.

Check the protocol and cipher settings your server negotiates. Current deployment guidance favors modern TLS versions and retiring legacy protocols and weak ciphers that expose sites to downgrade attacks.

### **Why It Matters**

A broken or missing certificate breaks trust immediately, and browsers now warn users away from sites that fail validation. A frequent real-world failure is a missing intermediate certificate, which can work in one browser and fail in another.

Certificate lifetimes are shrinking on a fixed schedule. The CA/Browser Forum set a phased reduction from 398 days to 200 days in 2026, 100 days in 2027 and [47 days by 2029](https://www.ssl.com/article/preparing-for-47-day-ssl-tls-certificates/), which makes renewal automation a genuine operational concern, not an annual afterthought.

### **How to Implement**

Run an external TLS scan to confirm the certificate chain, supported protocols and cipher suites in one pass. Set expiry alerts well ahead of the renewal date so a lapse never reaches production.

Enforce HTTPS everywhere with a redirect and an appropriate HSTS policy, so browsers refuse to downgrade the connection.

### **Common Pitfalls to Avoid**

Incomplete certificate chains cause the most trouble, because the site loads for you while failing for a first-time visitor whose browser has not cached the intermediate.

Self-signed certificates belong in development only. In production they produce browser warnings that drive users away.

## **3. Review Security Headers**

### **What to Check**

Security headers are instructions your server sends the browser about how to handle your pages, and the audit checks which ones you send. Look for Content-Security-Policy, which limits where scripts and styles may load from, X-Content-Type-Options set to nosniff, X-Frame-Options or a frame-ancestors policy to block clickjacking, and Strict-Transport-Security to lock in HTTPS.

Review the values, not just the presence. A header that exists but is misconfigured gives a false sense of safety.

### **Why It Matters**

Headers are a low-cost line of defense that shut down whole classes of browser-level attack, and they usually require little change to the application itself. A tuned Content-Security-Policy is one of the strongest defenses against cross-site scripting available to a web team.

Automated scanners grade a handful of critical headers and flag missing ones as findings, so gaps here surface quickly during any external review.

### **How to Implement**

Configure headers at the web server or CDN, not in application code, so they apply uniformly. On common servers this is a directive in the configuration file, per [vendor guidance](https://docs.veracode.com/r/enable-security-headers), and it should be tested ahead of the live release.

Start Content-Security-Policy in report-only mode, watch what it would block, then enforce it once legitimate sources are allowlisted.

### **Common Pitfalls to Avoid**

An overly permissive policy defeats its own purpose. A Content-Security-Policy that allows scripts from anywhere protects nothing.

Short HSTS max-age values weaken the guarantee, since browsers discard the policy quickly, per [Okta guidance](https://developer.okta.com/blog/2021/10/18/security-headers-best-practices). Apply headers consistently on every deployment so gaps do not appear between staging and live.

## **4. Audit CMS, Plugins, Frameworks and Outdated Dependencies**

### **What to Check**

[Your CMS and its extensions](https://www.darwinapps.com/digital-product-development/) are the most attacked part of most B2B websites, so the audit inventories every component and its version. List the CMS core, every active and inactive plugin or module, the theme, and the front-end and back-end frameworks the site depends on.

Compare each version against its current release and known vulnerability advisories. An outdated plugin with a public exploit is one of the most common ways a marketing site gets compromised.

### **Why It Matters**

Known vulnerabilities in outdated components are a fast-growing entry point. The Verizon [2025 DBIR](https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf) found that exploited vulnerabilities were the initial access vector in 20% of breaches, a 34% rise year over year, and attackers scan for these published flaws automatically.

First-time application scans routinely surface at least one vulnerability, so treating an unscanned stack as clean is a guess, not a finding.

### **How to Implement**

Maintain a dependency inventory and subscribe to advisories for every component in it. Automate scanning so a newly disclosed vulnerability in a plugin you run reaches you the same week.

Remove inactive plugins and unused themes entirely, because deactivated does not mean safe. Dormant code still ships to the server and can still be exploited.

### **Common Pitfalls to Avoid**

Leaving deactivated plugins installed is a frequent oversight. If the files are on disk, they can be reached.

Skipping updates on a site that "just works" is how a quiet marketing microsite becomes the breach that reaches your main infrastructure.

## **5. Check Access Controls and Authentication**

### **What to Check**

Access control decides who can reach what, and the audit examines authentication, session handling and authorization together. Pull the current list of accounts for every system that touches the website and its data: CMS admins, hosting, DNS, and any connected marketing platform.

Check whether you use [role-based access control](https://www.darwinapps.com/blog/what-is-ip-allowlisting-whitelisting/), which assigns permissions to roles, not to individuals and makes reviews far faster. Look for vertical gaps, where an ordinary user can reach admin functions, and horizontal gaps, where one user can reach another user's data.

### **Why It Matters**

Broken access control ranks among the most exploited weaknesses in real-world web attacks. The damage spreads into unauthorized data exposure and privilege escalation.

*“Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata.”*

[OWASP Top 10](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/), A01: Broken Access Control, 2025

Compromised credentials remain a leading breach cause. The Verizon [2025 DBIR](https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf) reports that stolen credentials were the initial access vector in 22% of breaches, and that 88% of attacks against basic web applications involved stolen credentials. That is why [multi-factor authentication](https://www.darwinapps.com/blog/10-multi-factor-authentication-mfa-best-practices-and-implementation-strategy/) on every privileged account matters so much.

### **How to Implement**

Apply least privilege: give each account the minimum access its job needs, and enforce authorization on the server, since hiding buttons in the interface is not enforcement. Require multi-factor authentication for all administrative access.

Cross-check the access list against your current staff roster, and remove accounts for people who have left. Review access on a schedule that matches the site's risk.

### **Common Pitfalls to Avoid**

Shared administrator accounts destroy accountability, since you cannot trace an action to a person. Give everyone their own credentials.

Relying on security questions for recovery is weak, because the answers often sit on public social profiles.

## **6. Find Exposed Secrets and Sensitive Information**

### **What to Check**

Exposed secrets are [credentials and keys that end up somewhere public](https://www.darwinapps.com/blog/best-data-privacy-tools-saas-marketing-teams/), and the audit hunts for them through the site's delivery. Inspect client-side JavaScript, HTML comments, exposed configuration files and public repositories for API keys, access tokens, database strings and internal endpoints.

Check what your error pages and directory listings reveal. Verbose errors and open directories hand attackers a map of your stack.

### **Why It Matters**

A single leaked key in front-end code can grant access to a connected service that stores far more than the website itself. Because the code runs in the browser, anyone can read it.

Secrets committed to a public repository are found quickly, since automated tools continuously scan public code for exactly this pattern.

### **How to Implement**

Keep secrets server-side and out of anything shipped to the browser. Route third-party calls through a backend so keys never appear in client code.

Scan your front-end bundles and repositories for credential patterns, and rotate any key that has ever been exposed, on the assumption someone noticed.

### **Common Pitfalls to Avoid**

Hard-coding an API key into client-side JavaScript for convenience is a recurring mistake, and it is trivial to extract.

Leaving default error verbosity on in production leaks stack traces and file paths that speed up an attacker's work.

## **7. Test Forms and Input Handling**

### **What to Check**

Forms are where your website accepts untrusted input, so the audit tests how every input is validated and sanitized. Cover every entry point: contact and demo forms, search boxes, file uploads, URL parameters and any API the front end calls.

Confirm validation happens on the server, because [client-side checks](https://www.darwinapps.com/blog/server-side-vs-client-side-tracking-which-delivers-more-reliable-ga4-data-in-2026/) are easily bypassed with browser tools or a proxy. Client-side validation improves the user experience but provides no security on its own.

### **Why It Matters**

Missing or weak input validation drives many web vulnerabilities, including cross-site scripting and SQL injection. For a B2B site, a vulnerable form is a direct line into the CRM or database behind it.

Validation alone does not stop every attack, though it reduces the attack surface and limits the damage when something does get through.

### **How to Implement**

Validate input as early as it arrives, using an allowlist of acceptable values and rejecting everything else. Use parameterized queries for every database call so input can never be executed as a command.

Sanitize and encode output based on where it is rendered, and treat file uploads as hostile until proven otherwise.

### **Common Pitfalls to Avoid**

Blocklist validation fails because no one can anticipate every malicious input. Allowlisting the acceptable set is the reliable approach.

Relying on sanitization while skipping parameterized queries leaves the SQL injection door open regardless of how clean the input looks.

## **8. Review Third-Party Scripts and External Integrations**

### **What to Check**

A third-party script loaded directly into a page can access and modify page content available to first-party JavaScript, so the audit inventories [every external script and integration on the site](https://www.darwinapps.com/blog/google-consent-mode-v2-mistakes-that-break-analytics-paid-media-reporting-and-retargeting/). List [analytics tags, chat widgets](https://www.darwinapps.com/blog/google-consent-mode-v2-implementation-checklist-for-saas-marketing-teams/), ad pixels, A/B testing tools and anything loaded from a domain you do not control.

Map where each integration sends data. A tag that captures form fields and ships them to an external service is part of your data-capture chain and belongs in the review.

### **Why It Matters**

A compromised third-party script executes in your users' browsers with full access to the page, including data entered into forms. Supply-chain attacks through analytics and widget vendors are a proven route to skimming customer data.

For a B2B site wired into a [CRM and analytics stack](https://www.darwinapps.com/blog/ga4-vs-crm-attribution-which-source-should-marketing-leaders-trust-for-revenue-reporting/), these integrations are exactly where the website meets the systems that hold your pipeline data. A weak link here exposes more than the page.

### **How to Implement**

Keep a living inventory of every external script and the vendor behind it, and remove tags no one uses anymore. Load third-party code with integrity checks where the vendor supports them.

Constrain what external scripts can do through your Content-Security-Policy, so a compromised vendor cannot exfiltrate freely.

### **Common Pitfalls to Avoid**

Tag sprawl is the common failure: marketing adds scripts over years and no one removes them, leaving forgotten vendors with access to every page.

Trusting a vendor's domain indefinitely ignores that the vendor itself can be breached. Review who still needs to be on the page.

## **9. Verify Logging, Monitoring and Backups**

### **What to Check**

[Logging tells you what happened](https://www.darwinapps.com/blog/a-complete-guide-to-network-security-monitoring/) and backups let you recover, so the audit confirms both exist and work. Check that access, error and administrative actions are logged, forwarded off the web server, and retained long enough to investigate an incident.

Confirm backups run on a schedule, are encrypted, and sit in storage separate from production so a single compromise cannot destroy both.

### **Why It Matters**

Without logs, a breach is invisible until the damage is public, and you cannot reconstruct how an attacker got in. Logs kept only on the compromised server disappear in the attack that mattered.

A backup you have never restored is an assumption. Recovery plans fail during real incidents precisely because no one tested the restore.

### **How to Implement**

Forward logs to separate storage and set alerts for [suspicious patterns such as repeated failed logins](https://www.darwinapps.com/blog/how-to-analyze-network-traffic-like-a-pro/). Retain enough history to investigate a slow-moving intrusion.

Follow a layered backup strategy with copies in more than one location, and test the restore on a schedule so you know it works before you need it.

### **Common Pitfalls to Avoid**

Storing backups only on the same infrastructure as production means one incident takes out both. Keep at least one copy elsewhere.

Skipping restore tests means you discover corruption during the recovery you were counting on.

## **10. Document Findings and Define Pentest Scope**

### **What to Check**

The audit is only useful if it ends in an ordered plan, so the final step turns findings into a ranked remediation list. Record every issue with its location, a severity based on real exploitability and business impact, an owner and a target date.

Separate what you can fix yourself from what genuinely needs specialist testing. That separation defines the scope of the penetration test you book next.

### **Why It Matters**

A pile of findings with no owners or dates changes nothing. Findings need structure: severity, ownership and [a remediation trail auditors and buyers can follow](https://www.darwinapps.com/blog/ai-agent-audit-logs-for-gtm-teams-what-to-track-before-automating-workflows/).

*“Defenders cannot afford to take weeks to patch systems that can be autonomously exploited en masse.”*

[Chris Butera](https://www.linkedin.com/in/chris-butera/), Acting Executive Assistant Director for Cybersecurity, CISA

Severity scores measure technical seriousness, not business risk. Two issues with the same score can carry very different real-world impact depending on which asset they sit on.

### **How to Implement**

Keep findings in one repository, rank them by exploitability and the value of the data at risk, and track remediation to closure. Fix the basics the audit surfaced before the pentest, so the engagement targets real depth.

Scope the penetration test around what the audit could not settle: business logic, chained exploits and anything requiring active attempts. Pair the non-exploitative external review with active testing where the risk justifies it.

### **Common Pitfalls to Avoid**

Treating the audit as a compliance checkbox, filed and forgotten, undermines the point. The list exists to drive fixes.

Handing an engineer-grade technical report to executives loses the audience. Pair it with a business-level view of the risk.

Get a free passive website security audit

We’ll inspect public assets, DNS, TLS, headers, components, third-party scripts, and email-security signals, then email you an evidence-based PDF.

## **Comparison Table**

![The image displays a table with various columns and rows of information about different software reviews. The table is organized into two main sections, each containing multiple rows filled with details about the software being reviewed. This comprehensive review allows users to easily compare and understand the features and benefits of each software option available for purchase or use.](https://cdn.sanity.io/images/qd0fa73p/production/47c893d9443613f7f9aafd41d057022a173671b9-1729x872.png?w=865&q=85&auto=format)

## **Turning a Website Audit Into Measurable Security Work**

For most teams the hard part is not the checklist itself, it is turning a long findings list into work that ships. An audit that names 40 issues and never ranks them or assigns owners produces activity with little to show for it, and the genuinely dangerous gaps sit next to cosmetic ones with no way to tell them apart.

This is the connection problem Darwin works on: keeping the website and the systems behind it dependable as they change. For [AlertMedia](https://www.darwinapps.com/work/alert-web-security/), Darwin set up automated checks that scanned every plugin and theme on the site every 12 hours, added [monthly reporting](https://www.darwinapps.com/blog/the-marketing-ops-sla-how-fast-should-teams-detect-tracking-and-routing-breaks/) and alerts to the right people, and cut vulnerability resolution time to 4 to 6 hours. The public site became a monitored, managed part of the stack, no longer a blind spot.

The order is what makes this work. A passive external audit finds the known weaknesses, remediation clears them in priority order, and a penetration test then targets the deeper risk that only active testing can reach. Run in that order, security testing spends its budget where it counts.

Get a free passive website security audit

We’ll inspect public assets, DNS, TLS, headers, components, third-party scripts, and email-security signals, then email you an evidence-based PDF.

## FAQs

**Q1. What is the difference between a website security audit and a penetration test?**

An audit is a non-exploitative external review: it looks at your public site, forms and integrations for known weaknesses and stops short of exploitation. A penetration test is active: a qualified partner attempts real attacks against a defined scope. The audit comes first so the pentest starts from a clean baseline.

**Q2. How often should we run a website security audit?**

Frequency depends on how often the site changes, its risk profile and any compliance requirements. A site under active development benefits from continuous or monthly checks, while a stable brochure site can run less often. The trigger that always matters is change: new code, a new integration or a new subdomain warrants a fresh look.

**Q3. Can a security audit replace a penetration test?**

No. An audit finds known, surface-level weaknesses and gives you a remediation list. A penetration test probes business logic, chained exploits and depth that passive review cannot reach. The two are sequential steps, and the audit makes the pentest more valuable by clearing the basics first.

**Q4. What does a website security audit cover in practice?**

A website-scoped audit covers your public attack surface, TLS configuration, security headers, CMS and dependency versions, access controls, exposed secrets, form handling, third-party scripts, and logging and backups. It ends with a ranked list of findings and a recommended scope for any specialist testing.

**Q5. Does passing an audit mean we will pass a penetration test?**

Not by itself. Clearing the audit removes the obvious issues and improves your odds. A penetration test can still surface deeper problems in logic or configuration. The honest goal is a clean baseline and a known scope. Treat it as readiness, never as a guarantee.

### Ready to see what your website exposes?

Darwin runs a free external security audit of your public site, forms and integrations, then hands you a prioritized remediation list.

![Andrei Kazhala](https://cdn.sanity.io/images/qd0fa73p/production/9da342d59bcb82c7e0785c35bf83128a41315c5e-840x840.jpg?w=420&q=85&auto=format)

###### You might also like

![The Step-by-Step Guide to SaaS Applications Development That Actually Works](https://cdn.sanity.io/images/qd0fa73p/production/6a5869560d4d34c2f9054311ed970ec66e6c5a3f-1492x840.png?w=746&q=85&auto=format)

## [The Step-by-Step Guide to SaaS Applications Development That Actually Works](https://www.darwinapps.com/blog/the-step-by-step-guide-to-saas-applications-development/)

![Successful Machine Learning Projects: Key Criteria for 2025 and Beyond](https://cdn.sanity.io/images/qd0fa73p/production/5af4865d877cf3ebd5b66bd04845c68d2beaeaa9-1492x840.png?w=746&q=85&auto=format)

## [Successful Machine Learning Projects: Key Criteria for 2025 and Beyond](https://www.darwinapps.com/blog/successful-machine-learning-projects-key-criteria-for-2025-and-beyond/)

![Coding vs Programming: What Are the Differences?](https://cdn.sanity.io/images/qd0fa73p/production/62ca5c2bb56f2821873804c58ee353bcfe807332-1492x840.png?w=746&q=85&auto=format)

## [Coding vs Programming: What Are the Differences?](https://www.darwinapps.com/blog/coding-vs-programming-what-are-the-differences/)