Website security audit

A website can look perfect and still be wide open. You only notice when someone asks, or when something goes wrong:

• An online scanner gives your site a D or an F, and you don't know what the letters mean or where to start.

• Your client or your IT asks for a security review, and nobody knows who sets what: the agency, IT or the hosting.

• There is a Content Security Policy, but with unsafe-inline. Or it was switched off once because the site broke.

• You don't know whether your CMS and its packages are up to date, or which admin paths are publicly reachable.

• A certificate expired once, and nobody saw it coming.

Much of a website's security isn't in the code, but in the settings around it. That's where a security audit starts.

You know where you stand.
For each area you see what's in order and what isn't, in plain language, with the technical details included.

You close the known gaps.
Clickjacking, third-party scripts that may do more than they need, cookies that travel where they shouldn't: you deal with them before someone uses them.

One list, with who fixes each point.
Us, your IT or your hosting partner. No more back and forth about who should do what.

You do first what matters most.
Every finding gets a severity and an estimate of the work. So you know what comes first.

You can show it.
To your clients, your IT or your management: with a report per area, and a new measurement after the changes.

Security headers

• HSTS: forces https, even on a first visit through an old link.

• X-Content-Type-Options, Referrer-Policy and Permissions-Policy.

• frame-ancestors or X-Frame-Options: against clickjacking.

• The Cross-Origin headers.

Content Security Policy

• Is there a CSP, and is it strict enough: nonces or hashes instead of unsafe-inline?

• Is it report-only or enforced?

• Do the reports arrive somewhere, and does anyone read them?

Certificate and domain

• Certificate, expiry date and protocol versions.

• Redirects to https and to one canonical host.

• DNS: CAA, and SPF, DKIM and DMARC for your domain's email.

What sits in front of your site

• CDN, WAF or firewall: how are the rules, bot management and rate limiting set up?

• Are sensitive pages cached?

Your platform

• The version of your CMS and its packages.

• Publicly reachable admin paths and allowed HTTP methods.

• Cookies: Secure, HttpOnly and SameSite.

• What error pages and headers give away, such as your server version.

Not a pentest. We don't try to break in and we don't test your application's logic. We look at how your website, your platform and what sits in front of it are set up. If you need a pentest, we'll tell you.

Not a malware scan. We don't actively look for malware. If we come across signs of it, we tell you right away.

Not a certificate. You get a report that shows where your site stands, not a label.

On blastic.com we apply what we check on yours:

• A Content Security Policy with a new nonce on every page, without unsafe-inline for scripts.

• The reports of that CSP come in at our end and we follow them up.

• HSTS with preload, and one redirect to https and to www.

• Only the HTTP methods the site needs.

Curious how your own site compares? Request the free quickscan and you get the same checks as a PDF.

1. Free quickscan. We run one URL through Mozilla Observatory, SSL Labs and ImmuniWeb and through our own readiness tool, and you get the result as a PDF.

2. The audit. We check your site, your platform and what sits in front of it, following the checklist above.

3. The report. For each finding the severity, the work and who fixes it: us, your IT or your hosting partner.

4. We go through it together. We decide together what comes first.

5. Fix and measure again. After the changes we measure again, so you see what it brought.

We make the changes in your platform. For what sits with your IT or hosting partner, we work with them, or take it over.

We also keep your platform itself safe: we install the security updates and patches for Sitecore, Kentico and Umbraco, and update third-party packages.

A secure site doesn't stay secure by itself. A new script from a marketing tool, a release or an expired certificate can open something up. With monitoring we follow up the CSP reports and watch your headers and certificate. That's part of hosting and support.

Every site is different, but we come across these often:

• A CSP that stops little. With unsafe-inline and unsafe-eval, or report-only without anyone reading the reports.

• No HSTS, or only for the main domain.

• Publicly reachable admin paths, with a login screen for everyone.

• The server version in the headers or on an error page.

• Cookies without Secure or SameSite.

• No DMARC, or DMARC on p=none, so anyone can send email in your domain's name.

Most of these are settings: set them right once, and they stay right.

That depends on how many domains and environments you have, on your platform and on what sits in front of your site. Start with the free quickscan. Then you know where you stand, and you get a tailored proposal.