Question 1

What does a passive security audit actually check?

Accepted Answer

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.

Question 2

What's the difference between passive and active testing?

Accepted Answer

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.

Question 3

How is the security score calculated, and why might I score lower than on other tools?

Accepted Answer

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.

Question 4

What are HTTP security headers and which ones matter most?

Accepted Answer

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.

Question 5

What is a Content-Security-Policy and why does an "unsafe-inline" CSP fail?

Accepted Answer

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 <script> block or an onerror= handler will run happily under a policy that allows inline script. Similarly, 'unsafe-eval' permits eval() and equivalent dynamic code execution, reopening another injection avenue. So a CSP containing unsafe-inline in script-src is, for the threat it's meant to stop, no better than having no CSP at all the header is present and looks reassuring, but the protection is disabled. That's why this audit treats an unsafe-inline CSP as a serious failure carrying a score-dominating penalty, rather than counting it as a partial pass. Tools that simply check "is a CSP header present?" will mark it green, which is misleading. The correct fix is to remove unsafe-inline and unsafe-eval from script-src and instead use nonces or hashes for any inline scripts that genuinely must run inline. It's more work than pasting a permissive policy, but it's the difference between a CSP that protects and a CSP that only appears to.

Question 6

What does the TLS/SSL check look at?

Accepted Answer

The TLS/SSL check performs a genuine handshake with your server not a header read and inspects the certificate and connection it gets back. First it confirms the certificate is valid: correctly formed, matching the hostname, and signed by a trusted certificate authority rather than self-signed or issued by an untrusted root. Second it checks expiry, and specifically flags certificates that are valid now but due to expire within the next thirty days, because an expired certificate takes a site offline for every visitor and the warning window is your chance to renew before that happens. Third it checks the negotiated protocol version, confirming your server uses a modern TLS version (1.2 or 1.3) and isn't still accepting the long-deprecated TLS 1.0 or 1.1, which have known weaknesses. It also verifies that a plain http:// request is redirected to https://, so a visitor who omits the scheme isn't silently served over cleartext. In plain security terms, this is the difference between the browser padlock being real and current versus expired, misconfigured or trivially spoofable. TLS failures are weighted heavily in the score because a broken or invalid certificate undermines the confidentiality and integrity of everything else if the encrypted channel itself can't be trusted, no amount of correct headers behind it helps. The check is read-only and completes in the same pass as the rest of the passive scan. Note that this validates the certificate and protocol as presented on the connection the scanner makes; a full cipher-suite enumeration and deep TLS configuration audit is a specialist task beyond the scope of a general passive scan, and tools like Qualys SSL Labs exist for that deeper analysis when you need it.

Question 7

What are the cookie security flags (Secure, HttpOnly, SameSite)?

Accepted Answer

Cookies frequently hold session tokens the credentials that keep a user logged in so how they're protected directly determines how easily an attacker can hijack a session. The audit inspects every Set-Cookie header for three flags. The Secure flag tells the browser to send the cookie only over HTTPS, never over an unencrypted connection; without it, a cookie can leak in cleartext to anyone able to observe the network. The HttpOnly flag makes the cookie invisible to JavaScript, which means that even if an attacker manages to run a cross-site scripting payload on your page, they can't read the session cookie and steal the session HttpOnly is one of the most effective mitigations against XSS-driven session theft. The SameSite attribute controls whether the cookie is sent on cross-site requests: set to Lax or Strict, it prevents the browser from attaching your session cookie to requests originating from other sites, which is a core defence against cross-site request forgery. Together these three flags turn a session cookie from something an attacker can steal or abuse into something meaningfully harder to reach. The audit reports on each flag for each cookie; where a site sets no cookies at all, the checks pass by default, since there's nothing exposed. A common real-world failure is a session cookie missing HttpOnly, which quietly converts any XSS bug on the site into a full account-takeover vector. Because the impact is session compromise, these are meaningful findings even though the fix is usually a one-line configuration change in the framework or server that issues the cookie.

Question 8

What is mixed content and why is it flagged?

Accepted Answer

Mixed content is when a page served over HTTPS loads one or more resources a script, stylesheet, image, font or iframe over plain HTTP. The problem is that the security of an HTTPS page is only as strong as its weakest sub-resource. If your page is encrypted but pulls in a script over http://, that script travels in cleartext and can be read or, worse, modified in transit by anyone positioned on the network. An attacker who can rewrite an insecurely-loaded script effectively controls your page, regardless of how well the main document is protected. That's why the audit flags it: a secure front door means little if there's an open window beside it. Mixed content also degrades the user's trust signal browsers downgrade or remove the padlock, and modern browsers block active mixed content (scripts, iframes) outright, which can silently break functionality. The audit inspects the page for http:// resource references on an https:// page and reports any it finds. The fix is straightforward in principle: serve every resource over HTTPS, update hardcoded http:// URLs to https:// or protocol-relative form, and for defence in depth add the upgrade-insecure-requests CSP directive, which tells the browser to automatically rewrite insecure sub-resource requests to secure ones. This check is passive and covers the page as fetched; because it inspects the delivered HTML and referenced resources, it catches the common cases where a template, plugin or third-party embed still points at an insecure URL. It's a low-effort, high-value fix closing it removes an entire class of in-transit tampering risk.

Question 9

How does the CVE / known-vulnerability check work?

Accepted Answer

A CVE Common Vulnerabilities and Exposures is a publicly catalogued, uniquely identified security flaw in a specific piece of software. The danger of running software with a known CVE is that the vulnerability is documented, often with a working exploit, and automated scanners actively sweep the internet looking for versions known to be affected. The audit's CVE check works by first fingerprinting the software and versions your site discloses through Server headers, X-Powered-By headers, CMS generator tags and similar version strings and then matching those detected versions against the NIST National Vulnerability Database, the authoritative public record of known vulnerabilities. If a version you're running has published CVEs, they're flagged. The plain analogy is checking whether your specific lock model appears on a burglar's "easy to pick" list: the flaw is already public knowledge, so the only question is whether you've patched past it. The check's reach depends entirely on what your site reveals this is a passive method, so if your server and application don't leak version information (which is itself good practice, and something the fingerprint check rewards), there may be no versions to look up, and the check reports that no fingerprints were available rather than claiming you're vulnerability-free. That's an important honesty distinction: "no CVEs matched" means "nothing known matched what we could detect," not a guarantee of no vulnerabilities. The correct response to a CVE finding is to upgrade the affected software to a patched release and, separately, to reduce version disclosure so you're not advertising exactly what to target. Keeping software current and subscribing to vendor security advisories is the durable fix; the audit surfaces the specific, already-public exposures that matter most.

Question 10

What is mail security DNS (SPF, DMARC, DKIM) and why is it in a security audit?

Accepted Answer

Mail-authentication DNS records determine whether someone can send email that appears to come from your domain and if they're missing or misconfigured, your domain can be spoofed in phishing and business-email-compromise attacks that damage your reputation and endanger your customers. That's squarely a security concern, which is why a thorough audit checks them even though they live in DNS rather than in HTTP responses. There are three records. SPF (Sender Policy Framework) is a DNS TXT record beginning v=spf1 that lists which mail servers are authorised to send on your domain's behalf; receiving servers check it to reject mail from unauthorised sources. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to your outgoing mail using a private key, which recipients verify against a public key published in your DNS proving the message genuinely came from you and wasn't altered in transit; the audit checks whether a signature resolves on common selectors. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together with a published policy telling receivers what to do with mail that fails authentication quarantine it, reject it, or merely report and is the record that actually turns SPF and DKIM into enforced anti-spoofing protection. Without DMARC, SPF and DKIM are advisory; with it, they have teeth. The audit confirms the presence of each. In plain terms, these records are what stop a scammer sending emails that look like they came from you a direct threat to anyone who trusts your domain. Publishing all three, with a DMARC policy set to at least quarantine, is the baseline for a domain that sends mail.

Question 11

What are CAA and DNSSEC, and why might DNSSEC show a warning?

Accepted Answer

Both are DNS-level protections against different attacks on your domain's integrity. A CAA (Certificate Authority Authorization) record names which certificate authorities are permitted to issue certificates for your domain. Without it, any CA in the world can issue a certificate for your name, so if an attacker tricks or compromises any one of them, they can obtain a valid certificate for your site. A CAA record restricts issuance to the CAs you actually use, sharply narrowing that mis-issuance risk. DNSSEC (DNS Security Extensions) cryptographically signs your DNS records so that resolvers can verify the answers they receive genuinely came from you and weren't forged or tampered with in transit the defence against DNS spoofing and cache poisoning, where an attacker secretly redirects your visitors to a fake copy of your site. The audit checks CAA presence and whether your zone is DNSSEC-signed, verifying the latter through a validating resolver's authenticated-data flag. DNSSEC often shows a warning for a specific and legitimate reason: it can only be enabled where the primary DNS provider manages signing and can publish the corresponding DS record at your registrar. If your domain runs on secondary (slave) DNS where your provider merely mirrors a zone hosted elsewhere DNSSEC frequently can't be enabled there, because the DS record must be managed by the primary DNS provider, not the mirror. In that situation the warning isn't a mistake you can simply toggle away; enabling DNSSEC would require moving primary DNS to a provider that manages it, or accepting that DNSSEC isn't available on your current setup. The audit explains this caveat rather than just telling you to "enable DNSSEC," because on many real-world configurations that instruction isn't actionable as stated.

Question 12

What does "server fingerprint" and CMS version disclosure mean?

Accepted Answer

Server fingerprinting is the practice of identifying exactly what software and which version a site runs, using the information the site volunteers about itself. The audit checks whether your server is leaking that information, because every precise version string you publish is a gift to an attacker. The Server response header sometimes advertises the exact web-server software and version; X-Powered-By can reveal the application platform and its version; and CMS platforms like WordPress, Drupal and Joomla often emit a generator meta tag stating their precise version. Individually these seem harmless, but together they let an attacker skip reconnaissance entirely: instead of probing to discover what you run, they read it off your responses, look up the known vulnerabilities for that exact version, and go straight to the exploits most likely to work. It's the difference between a burglar having to test your locks and being handed the make and model in advance. The audit flags verbose version disclosure and rewards its absence a Server header that says only nginx rather than nginx/1.2.3, no X-Powered-By, and a CMS that doesn't broadcast its version. This is also why the CVE check and the fingerprint check are related: reducing version disclosure both lowers your fingerprint risk and, as a side effect, means there's less for an automated CVE lookup to match against. The fix is configuration-level suppress or genericise these headers and remove generator meta tags and it costs nothing while removing a standing advantage from anyone scanning for easy targets. Reducing what you disclose won't fix an underlying vulnerability, but it removes the signposting that leads attackers to it.

Question 13

What do the active tests actually do, and are they safe?

Accepted Answer

The active tests are the audit's way of confirming a defence genuinely works, rather than merely being declared and they are deliberately built to be safe. There are four. The rate-limiting test sends a bounded burst of requests to an endpoint you nominate (typically a login or form-submit URL) and observes whether the site actually throttles them, confirming brute-force protection is enforced rather than just advertised. The access-control test requests pages you've told it should require authentication and checks they aren't served to an anonymous visitor catching protected areas that are accidentally reachable. The header-consistency test fetches several pages and compares their critical security headers, catching the common case where the homepage is hardened but inner pages are not. The upload-filter test submits inert, benign files under risky filenames to an upload endpoint you nominate, checking that dangerous types are rejected. What makes these safe is their design and their gating. No test sends an exploit payload, injection string, or anything intended to compromise the site; the requests are bounded in number, spaced politely so they don't stress your infrastructure, and every check verifies a defence rather than attempting to defeat it. They will not trip a well-configured WAF as an attack, because they aren't one. And every active test is locked behind proof of domain ownership you verify control via a DNS TXT record or a well-known file before any active check can target the domain so the tests can only ever run against a site you've demonstrably shown you control. Every field is optional; the header-consistency check always runs, and the others run only if you supply the relevant endpoint, so you test exactly what applies to your site and nothing more.

Question 14

Does this audit cover my whole site or just one page?

Accepted Answer

You choose. The audit has a scope selector with two modes. "This page" checks the exact URL you enter its HTTP security headers, Content-Security-Policy, cookie flags, mixed content and form handling all describe that specific page; use it to confirm a single page you've just hardened, since a site can serve a strict posture on one page and a weaker one on another. "Whole domain" checks your site root (homepage) as a representative view of the site-wide posture. Either way, some checks are domain-wide by nature and apply to your entire site regardless of scope: TLS certificate validity, mail-authentication DNS (SPF, DMARC, DKIM), CAA and DNSSEC, and the presence of well-known files all describe the domain as a whole. The page-level checks (headers, CSP, cookies, mixed content, forms) reflect whichever target the scope selects. This matters because a site can be hardened unevenly a strict page beside a weaker one and page mode lets you verify each page independently while cleaning them up one at a time. The result is always labelled with the scope that ran, so a passing result is never overstated into a claim about pages that weren't examined. For deliberate cross-page comparison, the active header-consistency test fetches multiple pages and compares their security headers directly. And if you're signed in, your run history saves each audit so you can track a page's score as you improve it. The honest summary: domain-level findings always cover the whole site; page-level findings cover exactly the scope you chose; and you pick page or domain depending on whether you're confirming one page or surveying the site.

🛡 Website Security Audit

1. What does a passive security audit actually check?

2. What's the difference between passive and active testing?

3. How is the security score calculated, and why might I score lower than on other tools?

4. What are HTTP security headers and which ones matter most?

5. What is a Content-Security-Policy and why does an "unsafe-inline" CSP fail?

6. What does the TLS/SSL check look at?

7. What are the cookie security flags (Secure, HttpOnly, SameSite)?

8. What is mixed content and why is it flagged?

9. How does the CVE / known-vulnerability check work?

10. What is mail security DNS (SPF, DMARC, DKIM) and why is it in a security audit?

11. What are CAA and DNSSEC, and why might DNSSEC show a warning?

12. What does "server fingerprint" and CMS version disclosure mean?

13. What do the active tests actually do, and are they safe?

14. Does this audit cover my whole site or just one page?

AI & LLM files

About aiwebpageseo