Clear, honest website audits — no subscriptions, no gimmicks.
Clear, honest website audits — no subscriptions, no gimmicks.
Our Understanding of Your Business
This is where we write what we know about your business from our search through your website and the internet.
This is a technical security hygiene score based on 23 automated,
externally-visible checks across 14 categories (equal weight per check: pass=1, warn=0.5, fail=0)
— it is not a penetration test verdict and does not test business logic, authentication flows,
or anything requiring credentials. A clean score here does not mean the site has no vulnerabilities; it means
these specific external configuration checks passed.
Categories checked: Cookies, Crawl, Email Authentication, Error Handling, Exposure, Hardening, Malware & Blacklist, Mixed Content, Open Redirect Exposure, Rate Limiting, Reachability, Security Headers, TLS, Third-Party Scripts.
http://www.example.com.au/ responds directly over plain HTTP (status 200) instead of redirecting to HTTPS.
Why it matters: Without a redirect, visitors who type the domain without 'https://', click an old http:// link, or follow a bookmark will load the site over an unencrypted connection with no warning -- exposing anything they submit (logins, forms) to interception on the network path, and triggering a browser 'Not Secure' warning.
Potential impact if fixed: Redirecting all HTTP traffic to HTTPS (a standard server/CDN config change) closes this gap for every visitor, regardless of how they arrived at the URL.
Recommended fix: Ask your host or developer to add a permanent (301) redirect from the plain HTTP version of every page to its HTTPS equivalent.
Missing entirely. (checked on 5 pages, consistent result).
Why it matters: HSTS tells browsers to always use HTTPS for this site, even if a visitor types or clicks an http:// link, closing the brief window where that first insecure request could be intercepted.
Potential impact if fixed: A strong HSTS policy (long max-age, includeSubDomains) is a one-time server config change that meaningfully strengthens HTTPS for every visitor.
Recommended fix: Ask your developer or host to add: Strict-Transport-Security: max-age=31536000; includeSubDomains
Missing entirely. (checked on 5 pages, consistent result).
Why it matters: CSP tells the browser which sources of scripts, styles, and other resources are allowed to load, which is one of the strongest defenses against cross-site scripting (XSS) attacks.
Potential impact if fixed: A well-configured CSP significantly reduces the damage a successful injection attack could do, even if some other flaw lets an attacker insert a script tag.
Recommended fix: This requires a developer to define which sources of scripts/styles/images this specific site actually needs -- it's not a one-size-fits-all value. Start with Content-Security-Policy-Report-Only while you inventory required sources, then switch to enforcing. Avoid a permissive policy (broad 'unsafe-inline' or wildcard sources) that provides little real protection. Test payment, upload, analytics, and any other app-specific routes before enforcing, since they're the most likely to break first.
Missing entirely (and no CSP frame-ancestors directive as an alternative). (checked on 5 pages, consistent result).
Why it matters: This prevents the site from being loaded inside an <iframe> on another site, which stops 'clickjacking' attacks that trick visitors into clicking something disguised as part of another page.
Potential impact if fixed: Adding this (or an equivalent CSP frame-ancestors directive) is a one-line fix that closes off clickjacking attacks entirely.
Recommended fix: Ask your developer to add: X-Frame-Options: SAMEORIGIN (or DENY if the site never needs to be framed).
DMARC policy is 'p=none' -- this only monitors and reports on failures, it doesn't actually instruct mail servers to reject or quarantine spoofed email impersonating this domain.
Why it matters: SPF and DMARC (along with DKIM, which this check can't verify without knowing the domain's DKIM selector) let receiving mail servers verify an email claiming to be from this domain is genuine, rather than a spoofed phishing/invoice-fraud attempt.
Potential impact if fixed: Publishing correct SPF and DMARC records (and moving DMARC from monitoring to an enforcing policy once confident) is a one-time DNS change that meaningfully reduces the ability of a scammer to impersonate this domain in email, which matters especially for a business sending invoices or account communications.
Recommended fix: Work with whoever manages DNS to publish a correct SPF record listing all legitimate sending sources, and a DMARC record starting at p=none for monitoring, moving to p=quarantine or p=reject once confident no legitimate mail is being missed. DKIM itself isn't checked here (its selector isn't discoverable without inside knowledge) -- confirm it separately with your email provider.
Missing entirely. (checked on 5 pages, consistent result).
Why it matters: This stops browsers from trying to guess ('sniff') a file's type differently than the server declared, which can be abused to trick a browser into executing a file as script when it shouldn't.
Potential impact if fixed: Adding 'nosniff' is a one-line, zero-risk fix that removes an entire class of content-type confusion attacks.
Recommended fix: Ask your developer to add: X-Content-Type-Options: nosniff
Missing entirely. (checked on 5 pages, consistent result).
Why it matters: This controls how much of the current page's URL is sent to other sites when a visitor clicks a link away from this page. Without it, full URLs (which can contain sensitive info in the path or query string) may leak to third parties.
Potential impact if fixed: Setting a reasonable policy (e.g. strict-origin-when-cross-origin) limits how much browsing information leaks to external sites.
Recommended fix: Ask your developer to add: Referrer-Policy: strict-origin-when-cross-origin
Missing entirely. (checked on 5 pages, consistent result).
Why it matters: This lets the site explicitly disable browser features (camera, microphone, geolocation, etc.) it doesn't use, so they can't be abused even if a malicious script gets injected somehow.
Potential impact if fixed: This is a defense-in-depth measure -- lower urgency than the headers above, but a good practice once those are in place.
Recommended fix: Ask your developer to add a Permissions-Policy header disabling browser features the site doesn't use, e.g.: Permissions-Policy: camera=(), microphone=(), geolocation=()
No signature from common WAF/CDN providers (Cloudflare, Sucuri, Akamai, Imperva, AWS WAF/CloudFront, Fastly, and others) was found in the response headers or cookies. This is a heuristic check based on known signatures -- it can't detect every WAF, and some WAFs (and platform-level protections built into hosts like Vercel, Netlify, or similar managed platforms) are configured not to leave a visible signature. Absence of a detected signature does not mean the site has no protection.
Why it matters: A WAF sits in front of the site and filters out common attack patterns (SQL injection attempts, known bad bots, DDoS traffic) before they ever reach the application, adding a layer of protection independent of the application code itself.
Potential impact if fixed: Adding or confirming WAF-style protection (particularly rate limiting and bot control) is a worthwhile hardening step, but it must complement secure code and monitoring -- it isn't a substitute for either.
Recommended fix: First confirm what protections your actual hosting platform already provides at the infrastructure level (many managed platforms include some by default without a detectable signature) and what your real threat model is, before assuming a dedicated WAF/CDN service needs to be added on top.
5 quick requests to the homepage all succeeded with no 429 response or Retry-After header. IMPORTANT: this is a very light check against the public homepage only (5 requests), not a load test and not a test of login, password reset, registration, uploads, or API endpoints -- it can't rule out rate limiting with a higher threshold, and many sites intentionally don't rate-limit the homepage itself while still limiting sensitive endpoints.
Why it matters: Without any rate limiting, endpoints like login forms or password reset are more vulnerable to automated brute-force or credential-stuffing attempts.
Potential impact if fixed: Adding rate limiting (often available as a one-click option on CDN/WAF providers like Cloudflare) is a broad, low-effort protection against automated abuse.
Recommended fix: This result is not validated evidence either way -- test rate limiting directly and with proper authorization on authentication, password-reset, registration, upload, and any costly/sensitive API endpoints specifically, with IP/account/device-aware limits and monitoring. See "Not Assessed" below.
The site is reachable over HTTPS. Status: 200.
Certificate is valid for www.example.com.au, expires in 77 day(s), using TLSv1.3 with a strong cipher (TLS_AES_256_GCM_SHA384).
TLS version negotiated: TLSv1.3
Cipher suite negotiated: TLS_AES_256_GCM_SHA384 (256-bit)
Certificate issuer: Let's Encrypt
Days until expiry: 77
Crawled 6 page(s) reachable via internal links, out of 5 URL(s) declared in the sitemap (the gap is typically pages the sitemap lists but nothing on the site links to — not a crawl limitation). robots.txt rules were respected.
None of the 5 page(s) checked set any cookies, so there's nothing to check flags on.
No external script/stylesheet domains detected on the homepage.
None of the 10 common sensitive paths checked were found accessible or listing directory contents.
No Disallow entries in robots.txt look like they're naming sensitive paths (admin, backup, config, credentials, etc.).
A clearly non-existent page correctly returned HTTP 404.
The error page response didn't match any of the common stack-trace/debug-page patterns SecureNow checks for.
Checked 5 page(s) -- no HTTP resources found loading on HTTPS pages.
Checked 5 page(s) for common redirect-parameter patterns (redirect=, next=, return_url=, etc.) in links and form actions -- none found.
No hidden spam links, suspicious hidden iframes, obfuscated script-injection, or defacement patterns were found on https://www.example.com.au/. This is a heuristic pattern scan, not a comprehensive malware analysis -- it doesn't rule out a genuine infection that doesn't match these specific patterns.
Google Safe Browsing has no malware, phishing, or unwanted software flags for this site.
This is a configuration/hygiene scanner, not a penetration test. Here is exactly what it does not cover, why, and how to get it done properly.
Why it wasn't assessed: No VirusTotal API key was provided, so only Google Safe Browsing's database was checked, not the other 70+ engines VirusTotal aggregates.
How to get this done:
Why it wasn't assessed: SecureNow's malware check is a lightweight heuristic pattern scan (hidden spam links, suspicious iframes, obfuscated scripts) plus, if a VirusTotal key is given, that service's own verdict -- it is not a comprehensive server-side file scan or behavioral analysis engine.
How to get this done:
Why it wasn't assessed: DKIM can't be checked the way SPF and DMARC are, because it's published under a domain-specific, arbitrary "selector" (e.g. selector1._domainkey.example.com) that isn't discoverable without knowing which one the mail provider uses.
How to get this done:
Why it wasn't assessed: This scan is entirely unauthenticated (no login credentials were used), so anything only visible after logging in — access control between user roles, privilege escalation, authenticated business logic — was not assessed.
How to get this done:
Why it wasn't assessed: SecureNow deliberately does not send any attack payloads, malformed input, or injection attempts to any form or parameter — it only observes configuration (headers, cookies, forms, exposed paths). Confirming whether an input field is actually vulnerable to SQL injection or XSS requires sending crafted test input and observing the response, which is active testing, not passive observation.
How to get this done:
Why it wasn't assessed: If the site accepts file uploads (profile pictures, documents, etc.), SecureNow does not test what file types are accepted, whether uploaded files are validated/sanitized, or where they're served from -- all of which require actually attempting an upload.
How to get this done:
Why it wasn't assessed: Confirming that a regular user genuinely cannot access another user's data (e.g. by changing an ID in a URL or API call -- an Insecure Direct Object Reference, or IDOR), or that a non-admin account can't reach admin functionality, requires logging in as multiple different accounts and testing -- entirely out of scope for an unauthenticated scan.
How to get this done:
Why it wasn't assessed: SecureNow observes whether a login form looks reasonably configured (POST method, CSRF token) but does not test the authentication logic itself -- account enumeration, lockout behavior, password reset token lifecycle, session fixation/revocation, or MFA bypass all require active testing of the actual flow.
How to get this done:
Why it wasn't assessed: This scan does not enumerate or test API routes -- authentication on each endpoint, object-level authorization, CORS configuration beyond the homepage, input validation, mass assignment, data leakage, and rate limits on the API itself are all out of scope for a homepage/page-level scan.
How to get this done:
Why it wasn't assessed: If the site processes payments or orders, this scan does not test for payment-status manipulation, price tampering, replay attacks, webhook signature verification, refund logic, or entitlement changes -- all of which require authenticated, transaction-level testing.
How to get this done:
Why it wasn't assessed: Automated scanning cannot judge whether a multi-step process (checkout, password reset, account recovery) has a logical flaw an attacker could abuse — this requires human judgment and manual testing.
How to get this done:
Why it wasn't assessed: This scan only looks at what's visible over HTTP(S) from outside — it does not check server patching status, open ports beyond 443, firewall rules, or internal network segmentation.
How to get this done:
Why it wasn't assessed: The Third-Party Scripts check only looks at which external domains are loaded, not whether specific JS libraries, server-side packages, or CMS plugins/themes have known vulnerabilities. This scan also cannot see inside your CI/CD pipeline, environment variables, source maps, or build artifacts to check for accidentally exposed API keys or secrets.
How to get this done:
Why it wasn't assessed: This scan cannot see your internal audit logs, alerting setup, backup schedule/encryption, or whether a practical incident-response process exists -- none of this is visible from outside the site.
How to get this done:
Why it wasn't assessed: This scan does not review what customer data is collected, where it's stored, who can access it, how long it's retained, or how a deletion request would be handled -- these are policy and data-architecture questions, not something visible from the outside of a website.
How to get this done:
Clear, honest website audits — no subscriptions, no gimmicks.