This is a sample report with example data — not a real scan. Run your own free scan to see your actual results.
Scan your own siteScan Results
Target: demo-bakery.example
Business Risk Checks
Grade: CEmail Spoofing Protection
SPF Record
✓ ConfiguredDMARC Policy
Policy: none
DKIM (Common)
✓ DetectedDMARC policy isn't enforced yet
You have a DMARC record, but its policy is set to "none," which means spoofed email is still delivered to inboxes as normal — you're only collecting reports, not actually blocking anything yet.
How to fix it: Once you've reviewed a few weeks of DMARC reports and confirmed your legitimate email sources (your email provider, any marketing or CRM tools) are all passing, update the policy to p=quarantine (spoofed mail goes to spam) or ideally p=reject (spoofed mail is rejected outright).
Learn more: what this means & the potential impacts→SSL/TLS Security
Your site's traffic is actively encrypted. The certificate expires in 214 days (6/1/2026).
Negotiates TLSv1.3 using TLS_AES_128_GCM_SHA256
Exposed Sensitive Files
✓ No exposed files foundChecked for common accidental exposures (.env files, .git directories, backup files) — none were found publicly reachable. Note: nothing about the file contents is ever retrieved, stored, or logged by this scan — only whether the path is reachable.
Cookie Security
A cookie is missing the HttpOnly flag
At least one cookie your site sets doesn't have the HttpOnly attribute, meaning any JavaScript running on the page can read it — including your own scripts, third-party scripts you've embedded (ads, analytics, widgets), and anything an attacker manages to inject via a cross-site scripting (XSS) vulnerability. HttpOnly cookies are invisible to JavaScript entirely, which removes that avenue outright.
How to fix it: Add the HttpOnly attribute to cookies that don't need to be read by client-side JavaScript — this is typically a single configuration flag alongside Secure (e.g. httponly=True in Flask/Django, cookie.httpOnly = true in Express). Note: some cookies are legitimately meant to be readable by JavaScript by design (e.g. a CSRF token cookie your frontend code needs to echo back) — HttpOnly should be applied to session/authentication cookies specifically.
Learn more: what this means & the potential impacts→A cookie has weak or missing SameSite protection
At least one cookie your site sets either has no SameSite attribute or is set to SameSite=None, meaning browsers will still attach it to requests that originate from a completely different website. That's the core mechanism behind cross-site request forgery (CSRF): a malicious page elsewhere on the internet can trigger a request to your site that automatically carries the visitor's real session cookie along with it.
How to fix it: Set the SameSite attribute to Strict or Lax on session and authentication cookies (Lax is the more compatible default for most sites, since it still allows the cookie on top-level navigation from external links). This is typically a single configuration flag alongside Secure and HttpOnly in your framework's session settings.
Learn more: what this means & the potential impacts→Missing Security Headers & Remediation
The following HTTP response headers are missing from your server configuration, leaving you exposed to common web vulnerabilities:
Content-Security-Policy
This header tells the browser exactly which sources of scripts and content your site trusts. Without it, if an attacker manages to inject malicious code onto your site — through a vulnerable plugin or a compromised form, for example — the browser has no guardrails stopping it from running.
Fix: Add a Content-Security-Policy header to your server's responses, e.g. Content-Security-Policy: default-src 'self'. This is a server configuration change — if you're not comfortable making it yourself, ask your host or developer to add it.
Learn more: what this means & the potential impacts→CMS & Platform Detection
WordPress detected
v6.5.2WooCommerceXML-RPC API is enabled
XML-RPC is an older WordPress feature used for remote publishing and "pingbacks." Most sites don't actually need it anymore, and it's frequently abused for the same brute-force login attempts as an exposed admin page, as well as to amplify denial-of-service attacks against other websites.
How to fix it: If you don't use an app that specifically requires XML-RPC (like the legacy WordPress mobile app), most security plugins — Wordfence and iThemes Security both do this — have a one-click option to disable it entirely.
Learn more: what this means & the potential impacts→This site also runs WooCommerce, so securing that login protects customer and order data too.
Detected plugins (2)
One or more plugins are out of date
Outdated plugins are one of the most common ways WordPress sites get compromised. When a plugin author releases a security fix, the update itself often reveals exactly what was vulnerable — giving attackers a roadmap to any site that hasn't updated yet.
How to fix it: Log into your WordPress admin dashboard (yoursite.com/wp-admin), go to Plugins, and update anything flagged below. If you're not comfortable making changes to your site directly, most web developers and agencies offer plugin updates as a quick, low-cost maintenance task.
Learn more: what this means & the potential impacts→woocommerce
v8.1.0
contact-form-7
v5.7 → latest v5.9
Detected passively from page assets, and may miss plugins that load no front-end files. This flags outdated versions only — it does not check for specific known vulnerabilities (CVEs) yet.
Domain Registration
Expires in 143 days
1/5/2027
DNS Records Found
The DNS records currently pointing at your domain — useful for confirming your setup matches what you expect. This section is informational, not a pass/fail check.
Advanced Hardening & Disclosure
These go beyond baseline requirements, and most sites don't have them configured yet — informational only, not factored into your grade.
CAA record
✗ Not setDNSSEC
✗ Not enabledsecurity.txt
✗ Not found