What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can perform a useful first-pass website security audit in 20 minutes by checking five controls at their real enforcement points: HTTP response headers for Content Security Policy (CSP) and HTTP Strict Transport Security (HSTS), and DNS records for SPF, DMARC and Certification Authority Authorization (CAA). The audit is only trustworthy when it captures the live production response, follows redirects, checks the relevant subdomains and records what changed.
This is a verification runbook, not a substitute for application testing. CSP reduces the impact of content-injection flaws, HSTS makes browsers prefer HTTPS, SPF and DMARC protect domain-based email identity, and CAA limits which certificate authorities may issue for a domain. Each control has a different failure mode and owner.
What to collect before the 20-minute audit
Choose the canonical production hostname and document the apex domain, redirect behavior, mail-sending subdomains and certificate names. A site may return different headers at the origin, CDN and reverse-proxy layers, while DNS answers can vary by resolver and cache. Record the UTC timestamp, hostname, response status, redirect chain and whether a CDN or reverse proxy handled the request.
Use a browser’s Network panel or an HTTP client for headers, and a validating DNS resolver for records. The following commands are examples; substitute the real production names and preserve the raw output in your audit notes:
curl -sS -D - -o /dev/null https://example.com
curl -sS -D - -o /dev/null -L http://example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig CAA example.com +shortDo not call a control “passing” because a configuration file contains the expected value. The live response or DNS answer is the evidence.
Minutes 0–3: establish scope and evidence
Define the browser-facing surface
- Identify the canonical HTTPS hostname and every HTTP-to-HTTPS redirect.
- List production subdomains that browsers, APIs, payment pages, login providers or embedded applications use.
- List every legitimate mail-sending service, including transactional, marketing, support and third-party platforms.
- List the certificate authorities currently used for public certificates and renewals.
Separate observations from expectations
Create one record per control with these fields: observed value, expected value, evidence command or response, risk, owner, proposed change, rollback and verification date. Use the states “missing,” “present but weak” and “present and verified.” This prevents a plausible-looking policy from being mistaken for a tested one.
Minutes 3–8: inspect and safely deploy CSP
Content Security Policy controls which scripts, styles, frames, connections, images, fonts, objects and forms a browser may use. The W3C specification describes CSP as a way to lock down applications, mitigate content-injection vulnerabilities such as cross-site scripting and reduce the privileges with which applications execute. It is defense in depth, not a replacement for input validation, output encoding, secure session handling or dependency review.
Check the enforced response header
Inspect the HTTPS response for Content-Security-Policy. The response header is the preferred delivery mechanism. At minimum, review these directives against what the application actually loads:
default-srcas the fallback policy.script-srcfor JavaScript origins, nonces or hashes.style-srcfor stylesheets and inline-style requirements.object-srcto control legacy plug-in content.base-urito restrict the document base URL.frame-ancestorsto control which sites may embed the page.form-actionto restrict form submission destinations.- Connection, image and font sources actually used by the application, such as the relevant
connect-src,img-srcandfont-srcvalues.
Review unsafe-inline and unsafe-eval as findings, not as automatic deletion targets. First identify the inline application code, analytics tag, payment widget, login provider or vendor that depends on them. Removing a required source without an owner and rollback can break a critical flow while creating no security improvement.
Move from observation to enforcement
If no enforced policy exists, deploy an equivalent Content-Security-Policy-Report-Only header. Report-only mode observes violations without blocking resources, allowing the team to collect real traffic and distinguish required origins from stale or unexpected ones. Review violations, remove origins that no longer belong, and assign each remaining dependency to an owner. Then enforce the policy and retest the application’s main journeys.
A strict policy can affect analytics, payment widgets, login providers and inline application code immediately. Test authenticated pages, checkout, account recovery, uploads, embedded media and administrative screens, not just the home page. Keep the report-only policy during rollout if your monitoring process can compare violations with the enforced policy.
Minutes 8–11: verify HSTS on HTTPS
HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS for a declared period. OWASP describes it as enforcing secure HTTP-over-TLS connections. Inspect it only on an HTTPS response: an HTTP response cannot safely establish the policy because an attacker could alter it in transit.
Check the header and redirect path
Look for Strict-Transport-Security on the canonical HTTPS response and record its max-age. Decide separately whether includeSubDomains is safe. Test an HTTP request, every redirect hop and representative subdomains. Confirm that each covered name has a valid certificate and a functioning HTTPS service.
Do not add includeSubDomains merely because it is common. An abandoned, legacy or vendor-managed subdomain can become unreachable for users when the browser upgrades it to HTTPS. Inventory DNS and hosting first, then test names that are easy to overlook, such as development remnants, regional hosts and old API endpoints.
Treat preload as an operational commitment
The preload directive is a separate commitment from ordinary HSTS. Pursue it only after every covered subdomain consistently serves HTTPS with valid certificates and the organization accepts the long-term operational consequences. Test certificate renewal, redirects, monitoring and incident recovery before making that commitment.
Free tools Windows power users keep installed
One-click scans. No signup required.
HSTS does not fix mixed content, an invalid certificate or an HTTP-only dependency. Those are separate defects that must be corrected even when the header is present.
Minutes 11–15: audit SPF and DMARC together
SPF: enumerate every authorized sender
Sender Policy Framework (SPF) is a DNS TXT authorization policy. RFC 7208 requires SPF records to be published as DNS TXT (type 16) resource records. Query the domain used by the envelope sender and inspect the complete answer, including nested include chains.
Build a sender inventory from actual mail flows. Include transactional systems, marketing platforms, support desks, ticketing tools and any service that sends as the domain. Remove stale includes for retired providers. An SPF record that names a service no longer used expands the attack surface and makes ownership unclear; an omitted legitimate provider causes SPF failures.
Inspect nested includes for unnecessary DNS lookups and document who owns each authorization. SPF alone does not authenticate the visible From address that readers see, so it must be evaluated with DKIM and DMARC.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #4
- Used Book in Good Condition
DMARC: check policy and alignment
DMARC is published as a TXT record at _dmarc.example.com (replace the domain with the one being audited). It evaluates SPF and DKIM, checks alignment with the visible From domain and applies a policy such as none, quarantine or reject. Optional aggregate and failure reports provide evidence about legitimate and abusive sending.
Record these tags when present:
pfor the policy applied to the domain.spfor a different policy on subdomains.ruafor aggregate-report destinations.ruffor failure-report destinations, if used.adkimfor DKIM alignment mode.aspffor SPF alignment mode.pctfor the percentage of messages to which the policy applies.
Check that report destinations are controlled by the organization and appropriate for the privacy obligations of the mail stream. Compare real message authentication results with the visible From domain: DMARC passes when SPF or DKIM authentication is aligned with that domain. A message can pass SPF yet fail DMARC if the authenticated envelope domain does not align.
Use a staged DMARC change
Start with p=none while collecting reports and fixing legitimate senders. Move toward quarantine or reject only after reports and sampled messages show that authorized systems pass alignment. Keep a change owner and rollback plan because a forgotten vendor can affect password resets, invoices or customer support mail.
The standards landscape changed on May 20, 2026: DMARC.org reports that RFC 9989 (core), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) were published and update or obsolete RFC 7489. Recheck implementation and provider behavior against the current RFC set when you make a policy change; do not assume older provider documentation describes every current detail.
Minutes 15–18: check CAA and certificate renewal
Certification Authority Authorization (CAA) is a DNS authorization control for certificate issuance. RFC 8659 defines it as a way for a domain name holder to specify the certificate authorities authorized to issue certificates for that domain.
Best Value
- Used Book in Good Condition
Inspect the effective records
Query CAA at the apex and relevant DNS ancestors. List every issue, issuewild and iodef value. Compare each authorization with the certificate authorities your organization actually uses, including separate authorities for wildcard and non-wildcard certificates. An unexpected authorized CA is a concrete finding.
A missing CAA record is not automatically a vulnerability: issuance may be governed by another control or operational process. The risk is clearest when an authorization is broader than the organization’s certificate strategy or when nobody owns renewal decisions. Before removing an incumbent CA, test the renewal path in the same DNS and certificate-management environment used in production.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Minute 18–20: write remediation that can be verified
Turn observations into changes with an owner, deadline and rollback. Record the exact header or DNS answer before editing it, then capture the new live response after deployment. DNS caching and provider workflows mean SPF, DMARC and CAA changes may not appear everywhere immediately; note the resolver, timestamp and propagation assumptions.
- Classify the finding as missing, present but weak or present and verified.
- State the smallest change that addresses the finding and name the service or team responsible.
- Define the rollback value, such as the prior header or DNS record, and how it will be restored.
- Verify browser behavior, mail authentication and certificate renewal paths after the change.
- Schedule a retest and retain the prior snapshot so a later regression is detectable.
How to judge the five controls consistently
| Control | Where to inspect | Evidence of a useful result | Typical failure to investigate |
|---|---|---|---|
| CSP | HTTPS response header | Directives match resources the application uses; unexpected origins are removed or owned | Missing policy, broad sources, or unexplained unsafe-inline/unsafe-eval |
| HSTS | HTTPS response header and HTTP redirect | Meaningful max-age; included names serve valid HTTPS |
Header seen only on HTTP, broken subdomain HTTPS, or premature preload commitment |
| SPF | DNS TXT at the sending domain | Every legitimate sender is represented and stale includes are removed | Forgotten provider, unnecessary nested includes or an incomplete sender inventory |
| DMARC | DNS TXT at _dmarc plus real message results |
SPF or DKIM aligns with visible From; reports are controlled; policy is intentional | Policy changed before legitimate senders pass, or report destinations are unmanaged |
| CAA | CAA at the apex and DNS ancestors | Authorized CAs match the renewal plan and wildcard needs | Unexpected authorization or removal of a CA before renewal is tested |
Choosing the right enforcement point
Implementation decisions should be compared on six axes: where enforcement occurs, the blast radius of a mistake, observability and reporting, support for multiple mail providers, certificate-renewal compatibility and operational ownership.
- Origin server: useful when one team owns the application response and deployment pipeline.
- CDN or reverse proxy: can apply headers consistently across origins, but verify that cached responses and bypass paths do not produce different policies.
- DNS: is the enforcement point for SPF, DMARC and CAA; changes depend on DNS caching and provider workflows rather than an application release.
CSP and HSTS can change browser behavior as soon as a new response is received. SPF, DMARC and CAA changes propagate through DNS caches and interact with external mail and certificate providers. That difference should determine the rollback window and the people who approve each change.
What a complete 20-minute result looks like
At the end of the runbook, you should have a timestamped snapshot of the production headers, redirect behavior and DNS answers; a list of real CSP dependencies; an HSTS subdomain decision; an SPF sender inventory; DMARC alignment and report findings; and a CAA authorization list tied to renewal ownership. Any item that cannot be tied to live evidence remains an open verification task rather than a pass.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems
