Website Security Scorecard

This scorecard assesses your website's security posture across four categories: HTTPS and security headers, access control, software currency, and data protection. It is a self-assessment — no scan is performed against your site. The score reflects how well you have implemented the baseline controls that defend against the most common web attacks (XSS, CSRF, credential stuffing, SQL injection, and ransomware via outdated software).

Why these controls matter

HTTPS and headers defend against man-in-the-middle attacks, clickjacking, and cross-site scripting. Access control prevents unauthorised access to admin panels, which is the attack vector in the majority of CMS compromises. Software updates close known CVEs — over 60% of breaches involve exploiting a known, patchable vulnerability. Backups and data hygiene limit the impact of a successful attack and determine whether ransomware results in data loss or a manageable incident.

What this scorecard does not cover

This is a baseline hygiene assessment, not a comprehensive security audit. It does not cover: penetration testing findings, application-layer vulnerabilities in custom code (IDOR, business logic flaws), supply chain risks, staff phishing susceptibility, or infrastructure-level configuration. For a comprehensive assessment, a professional penetration test or security audit is required.

A note on technical implementation: a live header scanner cannot be built into this static page due to browser CORS restrictions — cross-origin HTTP requests are blocked. The tool is structured as a self-assessment for this reason. ruxox can run a server-side technical audit as part of an engagement.

Security headers are instructions your server sends with every response, telling the browser to enforce protections it would otherwise leave off.

Start with the cheap ones

Four of the six are single lines with essentially no risk of breaking a working site: HSTS, X-Content-Type-Options, X-Frame-Options and Referrer-Policy. Add them first. Content-Security-Policy is the powerful one and the one that takes work — a strict policy blocks inline scripts and third-party resources, so deploy it in report-only mode, watch what it would have blocked, then enforce.

What a header check does not tell you

This is a surface check. It says nothing about SQL injection, broken access control, weak authentication, outdated dependencies with known CVEs, exposed admin panels, or leaked credentials in your repository — and those cause most real breaches. Perfect headers on an application with an authorisation bug is a locked front door on an unlocked house.

Where to go next

Keep dependencies patched, enforce HTTPS everywhere, use parameterised database queries, check authorisation on every request rather than only hiding UI, and put multi-factor authentication on anything administrative. Those five cover far more real-world risk than any header.