Canonical URL: https://aiwebpageseo.com/combined-audit.html Owner: AI Web Page SEO Contact: advice@aiwebpageseo.com Documentation: https://aiwebpageseo.com/aipageseo-demo-pages/ AI usage permissions: This page and its content may be accessed and used by AI crawlers and language models for indexing, summarisation, and training purposes. No restrictions apply to automated AI access to this page. # 🛡 Website Security Audit A passive security scan of any public website HTTP security headers, TLS configuration, cookie flags, mixed content, server fingerprint, known CVEs via the NVD database, CMS detection, mail DNS records and security.txt, with no active payloads sent to your target. For domains you verify you own, an optional **active testing** tier confirms defences actually work live rate-limit, access-control, header-consistency and upload-filter checks. Public URLs only. Private/internal addresses are rejected. These send real (but bounded & polite) requests to your verified domain to confirm your defences actually work. **Every field below is optional** fill in the ones that apply to your site and leave the rest blank. The header-consistency check always runs; the others only run if you give them something to test. Not sure whether you have one? Leave it empty and that check is simply skipped nothing breaks. The AI fix prompt only covers changes to your site's own files (HTML, CSS and JavaScript), never server, hosting or DNS settings. Those are listed separately, and if you'd like them done for you, you can request a quote. Back up your site before letting any AI tool change it. Drop a button into your own site so your visitors can run this security audit on the page they’re viewing. It opens the audit here with the URL already filled in — they just press Run. Two versions: a simple link, or a smart one that always audits whichever page it sits on. Enter the page you want the button to audit, then copy the snippet into your CMS. Best for locked-down site builders (Wix, Squarespace, some WordPress) that strip scripts. Your button’s audit link updates below as you type. Paste this once. It automatically audits whichever page it’s on, so the same snippet works across your whole site. Needs a CMS that allows a small inline script (self-hosted WordPress, custom HTML blocks, raw-HTML embeds). - **TLS / SSL** live certificate validity, expiry and protocol version (via a real TLS handshake). *In plain terms: checks the padlock in the browser bar is real, current and using modern encryption not expired, misconfigured or faked.* - **Known CVEs** detected software versions matched against the NIST National Vulnerability Database (NVD). *In plain terms: if your site runs software with publicly known ways in, we flag it like checking whether your lock model is on a burglar's "easy to pick" list.* - **Cookie flags** Secure, HttpOnly and SameSite on every cookie. *In plain terms: makes sure the little files that keep you logged in can't be stolen or read by an attacker.* - **Mixed content** http:// resources loaded on an https:// page. *In plain terms: catches secure pages that quietly pull in insecure parts a locked front door with a window left open.* - **Forms & input handling** HTTPS form submission, CSRF-token presence and secure file-upload transport (passive; homepage forms only). *In plain terms: checks that anything you type or upload is sent securely and can't be hijacked by a malicious site.* - **Rate limiting & abuse protection** presence of RateLimit-* / Retry-After response headers (a passive signal; the active tier can confirm enforcement on domains you own). *In plain terms: whether your site slows down attackers trying thousands of password guesses and, if you own the domain, whether that limit actually kicks in.* - **Mail security DNS** SPF, DMARC and DKIM records that stop your domain being spoofed. *In plain terms: stops scammers sending emails that look like they came from you.* - **DNS security** CAA (restricts which CAs may issue your certs) and DNSSEC (cryptographically signed DNS). *In plain terms: controls who's allowed to issue certificates for your domain, and helps stop people being secretly redirected to a fake copy of your site.* - **Server fingerprint** version strings leaked in Server / X-Powered-By headers. *In plain terms: checks your server isn't announcing exactly what software and version it runs information that helps attackers target it.* - **CMS exposure** WordPress / Drupal / Joomla version disclosure. *In plain terms: makes sure your website builder isn't broadcasting its exact version, which tells attackers which known weaknesses to try.* - **Well-known files** robots.txt and security.txt (RFC 9116). *In plain terms: checks you publish the standard files that tell search engines what to index and give security researchers a way to report problems to you.* - **HTTP security headers** (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, CORP) are evaluated against Mozilla's HTTP Observatory scoring model and the OWASP Secure Headers Project. - **TLS / SSL** is checked by a live handshake, following the Qualys SSL Labs and Mozilla TLS guidelines for protocol version, certificate validity and cipher strength with SSL Labs cited as the arbiter for cipher ordering. - **Known vulnerabilities** are matched against the NIST National Vulnerability Database (NVD). - **Content-Security-Policy** is analysed directive by directive, consistent with Google's CSP Evaluator and Mozilla's CSP guidance. - **Mail security** (SPF, DMARC, DKIM, MTA-STS, TLS-RPT, DANE) follows the relevant IETF RFCs. - **DNS** checks (CAA, DNSSEC) and **security.txt** (RFC 9116) follow their published specifications. Check whether web content is out of date. Enter a URL and we fetch the page, or paste content directly. We identify time-sensitive claims and check each against current Google results. Works on any site and any content. This check can take between 2 and 10 minutes — each claim is verified against live search results, so it runs as a thorough background pass rather than an instant scan. What each part of the audit checks, why it matters, and how to read the findings. If you've run a scan and want to understand a specific result, this covers the reasoning behind every check family. ### 1. What does a passive security audit actually check? A passive audit inspects everything a website reveals about itself through the ordinary requests a browser and a DNS resolver already make no intrusive probing. It reads your HTTP response headers to see which browser-level protections are set: Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the cross-origin isolation headers. It performs a real TLS handshake to confirm your certificate is valid, unexpired and negotiating a modern protocol version. It examines every `Set-Cookie` header for the Secure, HttpOnly and SameSite flags. It looks for mixed content insecure `http://` resources loaded on a secure page. It fingerprints your server and any CMS from version strings they leak, then matches detected versions against the NIST National Vulnerability Database to flag known CVEs. On the DNS side it checks your mail-authentication records (SPF, DMARC, DKIM), your CAA record, and whether the zone is DNSSEC-signed. Finally it confirms you publish the expected well-known files, robots.txt and security.txt. Every one of these is read-only reconnaissance: the same traffic a normal visitor generates, plus public DNS lookups. Nothing is injected, nothing is brute-forced, and no endpoint is stressed. That's the deliberate boundary of the passive tier it tells you what your site advertises about its own posture, which is a surprising amount, without ever behaving like an attacker. To confirm that a defence actually *works* rather than merely being declared, you use the active tier on a domain you've verified you own. ### 2. What's the difference between passive and active testing? The passive scan reads; the active tier verifies. A passive check can tell you a `RateLimit` header is present, or that a CSP is declared, or that a page returns a 401 but reading a response can never prove the underlying control actually enforces anything. A site can advertise rate-limit headers and still let an attacker make ten thousand login attempts; it can serve a strict-looking CSP on the homepage and a broken one three pages deep. Active testing closes that gap by sending real, bounded requests and observing behaviour. It confirms that rate limiting genuinely throttles repeated requests, that pages you expect to require authentication aren't reachable anonymously, that your security headers are applied consistently across multiple pages rather than just the homepage, and that a file-upload endpoint rejects dangerous file types. Crucially, active testing is still not attacking. There are no exploit payloads, no injection strings, no attempts to break in the checks are polite, rate-limited, and designed to confirm a defence holds, not to defeat it. Because these requests genuinely hit your infrastructure, the active tier is gated behind proof of domain ownership: you add a DNS TXT record or a well-known file, the same verification standard Google Search Console and Let's Encrypt use, and only then can active checks run against that domain. This means you can never point active testing at a site you don't control. The passive scan runs on any public URL in seconds (typically well under a minute); the active tier is the deliberate, authorised second step for confirming your own defences do what they claim. ### 3. How is the security score calculated, and why might I score lower than on other tools? Most scanners total up points for everything you pass, which means a single dangerous failure gets diluted by a wall of green ticks you can "score 90" while your Content-Security-Policy is fundamentally broken. This audit does the opposite. You start at 100 and lose points weighted by how dangerous each specific failure actually is. Passing checks never inflate the score to hide a failure; one critical problem drops the grade hard regardless of how many minor checks pass, because in security a single unlocked door matters more than ten locked windows. The weighting reflects real risk: a broken CSP or an invalid TLS certificate costs far more than a missing robots.txt. A CSP that allows `unsafe-inline` or `unsafe-eval` in `script-src` is treated as seriously as having no CSP at all because it defeats CSP's core cross-site-scripting defence either way and carries a score-dominating penalty rather than counting as one tick among many. This is why you can score lower here than on a tool like Mozilla Observatory while being flagged for the same underlying issue: the finding is the same, but it's weighted by consequence rather than counted. The intent is a score you can trust as a genuine risk signal. A high number here means the things that would actually hurt you are handled, not that you accumulated enough small passes to bury a serious one. If your score dropped after a change, look for a high-severity failure that single item is doing most of the work, and fixing it will move the grade far more than clearing several minor warnings. ### 4. What are HTTP security headers and which ones matter most? HTTP security headers are instructions your server sends with every response that tell the browser how to behave defensively. They're one of the highest-leverage security controls available because they're enforced by the browser itself, on every visitor, without touching your application code. The audit checks the full set and weights them by impact. Content-Security-Policy is the most consequential: it restricts which sources of script, style and other resources the browser will load, and a well-formed CSP is the single strongest defence against cross-site scripting. Strict-Transport-Security (HSTS) forces browsers to use HTTPS and refuse to downgrade, defeating protocol-downgrade and SSL-stripping attacks; the audit also checks the policy is strong a long max-age with includeSubDomains because a weak HSTS policy barely sticks. X-Frame-Options (or a CSP frame-ancestors directive) prevents your pages being embedded in a malicious iframe, blocking clickjacking. X-Content-Type-Options stops browsers MIME-sniffing responses into an executable type. Referrer-Policy controls how much of your URL leaks to other sites. Permissions-Policy restricts access to sensitive browser features like camera, microphone and geolocation. The cross-origin isolation headers (CORP, and CORS behaviour) govern which other origins can embed or read your resources, mitigating a class of cross-origin data leaks. Of these, CSP and HSTS carry the most weight in the score because their absence or misconfiguration exposes the most serious attack classes. The others are important but lower-consequence. A common and dangerous mistake is declaring a CSP that still permits `unsafe-inline` scripts the header is present, but the protection it exists to provide is switched off, which is why the audit flags that case as severely as a missing policy. ### 5. What is a Content-Security-Policy and why does an "unsafe-inline" CSP fail? A Content-Security-Policy is a header that tells the browser exactly which sources it's allowed to load scripts, styles, images, fonts and other resources from. Its central purpose is to neutralise cross-site scripting: even if an attacker manages to inject markup into your page, a strict CSP means the browser refuses to execute any script that didn't come from an approved source. This is why CSP is considered the strongest browser-level XSS defence available. The catch is that CSP only works if it's actually restrictive. The directive `script-src 'unsafe-inline'` tells the browser to execute any inline script it finds on the page which is precisely the mechanism most XSS attacks rely on. An injected `