Short answer: a website security audit for a typical business site checks six areas, in this order of impact:
- HTTPS and the TLS certificate (valid, not expiring, HTTP redirects to HTTPS).
- HTTP security headers (HSTS, Content-Security-Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
- Cookie flags (Secure, HttpOnly, SameSite).
- Email authentication (SPF and DMARC) so nobody can send mail as your domain.
- DNS protections (CAA and DNSSEC).
- A security contact in
/.well-known/security.txt.
You can check all six passively, without touching login forms or attacking anything, using the free ZetsApp Website Security Audit. It returns a weighted score and a PDF report you can hand to your developer.
What a passive audit is (and is not)
A passive audit reads what your server already sends to every visitor: response headers, the certificate, cookies and public DNS records. It does not log in, fuzz forms or try exploits, so it is safe to run on a live site at any time.
It is not a penetration test. It will not find an SQL injection bug in your checkout or a broken access check in your admin panel. Think of it as the first layer: it catches the configuration mistakes that are cheap to fix and that attackers and browsers check first. For the application layer, use the OWASP Top 10 as your test plan.
Step 1: HTTPS and certificate health
- Open
http://yourdomain.com(no "s"). It should redirect with a 301 to the HTTPS version in one hop. - Check the certificate covers both
yourdomain.comandwww.yourdomain.com. - Check the expiry date. Automate renewal; expired certificates are still one of the most common outages.
- Look for mixed content: images or scripts loaded over plain HTTP on an HTTPS page.
Step 2: HTTP security headers
These headers tell the browser how strictly to treat your site. Each is one line of server or CDN config.
| Header | What it prevents | Safe starting value |
|---|---|---|
| Strict-Transport-Security | Downgrade to HTTP, cookie theft on public Wi-Fi | max-age=31536000; includeSubDomains |
| Content-Security-Policy | Cross-site scripting, injected third-party scripts | Start in report-only mode, then enforce |
| X-Frame-Options / frame-ancestors | Clickjacking | SAMEORIGIN |
| X-Content-Type-Options | MIME-type sniffing attacks | nosniff |
| Referrer-Policy | Leaking full URLs (with tokens) to other sites | strict-origin-when-cross-origin |
| Permissions-Policy | Unwanted camera, microphone or location access | Disable what you do not use |
For the full reasoning and copy-paste configs for Nginx, Apache, IIS, Vercel and Cloudflare, see our security headers checklist.
Step 3: Cookies
Every cookie that carries a session or login state should have three flags:
- Secure: only sent over HTTPS.
- HttpOnly: not readable by JavaScript, so an XSS bug cannot steal it.
- SameSite=Lax (or Strict): not sent on most cross-site requests, which blocks classic CSRF.
Analytics and marketing cookies matter less for security but more for privacy law; make sure your consent banner actually blocks them until consent.
Step 4: Email authentication (SPF and DMARC)
Even if your website is perfect, attackers can send invoices "from" your domain unless you publish two DNS records:
- SPF lists the servers allowed to send mail for your domain. Keep it to one record and under 10 DNS lookups.
- DMARC tells receivers what to do with mail that fails checks. Start at
p=nonewith reports, move toquarantine, thenreject.
Gmail and Yahoo have required SPF, DKIM and DMARC for bulk senders since 2024, so this also protects your deliverability.
Step 5: DNS protections (CAA and DNSSEC)
- CAA records name the certificate authorities allowed to issue certificates for your domain. It is one record and blocks mis-issuance by other CAs.
- DNSSEC signs your DNS so answers cannot be forged. Enable it at your registrar if your DNS host supports it.
Step 6: security.txt
Publish /.well-known/security.txt (RFC 9116) with a Contact: email and an Expires: date. When a researcher finds a problem, they know where to report it instead of posting it publicly.
How to read your score and prioritise fixes
| Priority | Fix first if you see | Typical effort |
|---|---|---|
| Critical | No HTTPS, invalid or expired certificate, no HTTP-to-HTTPS redirect | Under an hour |
| High | Missing HSTS or CSP, session cookies without HttpOnly/Secure, no DMARC | Half a day |
| Medium | Missing frame protection, nosniff, Referrer-Policy, SPF too permissive | An hour |
| Low | No CAA, no DNSSEC, no security.txt, server version banners | An hour |
The ZetsApp scanner caps the score when HTTPS fails or the certificate is bad, because nothing else matters until that is fixed.
How often to audit
- After every deployment that changes hosting, CDN or framework.
- Monthly as a quick check (certificates and DNS change silently).
- Before a security questionnaire from a customer, an insurer or a compliance audit.
Frequently asked questions
Is a free website security scan enough?
It is enough to catch configuration problems, which are the most common issues on small business sites. It is not enough if you handle payments, health data or user accounts; those need an application security review or penetration test as well.
Is it legal to scan any website?
A passive check only reads what the site sends to every visitor, the same as a browser. Active testing (trying logins, injecting payloads) requires the owner's written permission.
Will adding security headers break my site?
HSTS, nosniff, Referrer-Policy and frame protection rarely break anything. Content-Security-Policy can block scripts, so deploy it in report-only mode first and fix what it reports.
What score should I aim for?
Aim to clear every critical and high finding. A score in the 80s or above with no critical items is a solid baseline for a business website.
Run your audit
Open the free Website Security Audit, enter your domain and download the PDF. If you want the fixes done for you, our team can harden the site as part of cloud and DevOps services.
