A technical account of how luisferreira.pt moved from B (84) to A (97) on SecurityScorecard in about 75 minutes, without installing a single new plugin and without touching WordPress. More important than the outcome: the three deliberate decisions not to fix certain issues, and why.

Context

The luisferreira.pt site was launched in January 2026 on a conventional stack: WordPress 6.9 with the Astra theme, Spectra page builder, Hostinger Business hosting, and Cloudflare PRO at the edge. On 4 May 2026, a visual and content redesign was carried out, keeping the original stack. Six days after this redesign, the SecurityScorecard assessment placed the site at 84 (B), with 7 open issues.

The distribution of issues was telling: 1 high-risk and 6 low-risk, all concentrated in the Application Security factor (rated 73, grade C). The other six factors — Cubit Score, DNS Health, Endpoint Security, Hacker Chatter, IP Reputation, and Network Security — were all at 100 (A).

The declared objective was to reach grade A, close to 100, with one condition: every action had to pass an ROI filter. This was not an emotional campaign (“I want to be A”); it was a rational one (“is being A worth it — and at what cost?”).

Diagnose before acting

The first step was not to fix anything. It was to cross-reference sources.

SecurityScorecard pointed to 7 concrete issues. In parallel, Snyk’s securityheaders.com graded the same site as A+. This apparent contradiction was informative, not problematic: the two tools measure different things.

• securityheaders.com checks presence of HTTP security headers.
• SecurityScorecard checks quality of those headers and looks for more granular patterns.

Where securityheaders.com awarded A+ for the presence of HSTS, SecurityScorecard flagged real deficiencies: max-age of only 180 days (recommended: 1 year or more), absence of includeSubDomains, absence of preload. The existing CSP was minimalist (upgrade-insecure-requests; only), missing the modern frame-ancestors directive against clickjacking. The X-Content-Type-Options: nosniff header appeared on some endpoints but not others.

For the highest-impact issue — “Unsafe Implementation of Subresource Integrity” (SRI), worth −9.3 points — a full inventory was made of all cross-origin scripts loaded by the site, using curl and analysis of the rendered HTML. The result was unexpected: the only cross-origin script was Cloudflare Turnstile (CAPTCHA). All other scripts were same-origin, served from luisferreira.pt.

A single tool rarely tells the whole story. When A+ from one source coexists with C from another, the answer is not to pick one — it is to understand what each one measures.

This diagnostic phase took about 15 minutes. Without it, the rest of the intervention would have headed in wrong directions.

Execution: edge-first hardening

Remediation was carried out entirely at the Cloudflare edge. Zero changes to WordPress, zero plugins installed, zero new code added.

The edge-first strategy rests on four practical advantages:

• Reversibility. Every change is undone with a single toggle in the Cloudflare panel.
• Independence. It survives theme updates, plugin updates, and even hosting migrations.
• Performance. It runs at the edge, before reaching the origin’s PHP cycle.
• Auditability. All rules live in one centralised panel.

Four changes were applied:

Each change was validated immediately with curl -sI to confirm the actual result in the HTTP response. The rule is simple: trust real responses, not configuration interfaces.

Important operational caveat: enabling HSTS preload is a decision that is hard to reverse. It commits the site to serving HTTPS on all current and future subdomains for the max-age duration (1 year). Before enabling, it was verified that no HTTP-only subdomains exist.

The three decisions not to act

The most valuable part of this intervention is not in what was done. It is in what was deliberately left undone, and in the technical justification for each decision.

Decision 1 — Do not implement an SRI Worker

SecurityScorecard flagged “Unsafe Implementation of Subresource Integrity” with recoverable impact of 9.3 points. At first glance, it was the most obvious win in the campaign.

The diagnostic revealed a different reality. The only cross-origin script was challenges.cloudflare.com/turnstile/v0/api.js — Cloudflare’s CAPTCHA loader. By design, this loader does not support SRI: it is a dynamic script that silently auto-updates whenever Cloudflare updates the anti-bot engine. Applying SRI would mean the CAPTCHA breaks every time Cloudflare updates — a silent degradation of the contact form.

All other scripts were same-origin, some of them bundles generated dynamically by LiteSpeed Cache, whose hashes change on every plugin update. Implementing SRI in that context would require a Cloudflare Worker that: fetches the resource, computes SHA-384 at runtime, maintains a synchronised hash cache, and handles cache-miss scenarios. Permanent operational complexity to solve a security problem that, in fact, did not exist.

The decision was to submit feedback to SecurityScorecard with documented technical justification. Cost: five minutes. Risk of future regression: zero.

Decision 2 — Do not refine the CSP

The Content Security Policy applied is minimalist: upgrade-insecure-requests; frame-ancestors 'self';. It addresses the two most relevant vectors (mixed content and clickjacking) and nothing more.

SecurityScorecard flagged this CSP as “Contains Broad Directives”, worth roughly 0.2 recoverable points. Refining with default-src, script-src, style-src, connect-src, and related directives would require a complete inventory of all assets legitimately loaded by the site, including plugins, third-party integrations, and dynamically injected scripts.

The cost is not in the initial inventory. It is in maintaining it. Every plugin update, every new integration, and every A/B test can introduce an unforeseen asset, breaking the site silently — because CSP, when violated, simply blocks with no visible warning on the frontend. Regression diagnosis requires browser console inspection, and is not caught by typical uptime monitors.

Trading 0.2 points for a permanent source of silent bugs is not a deal.

Decision 3 — Do not replace the CAPTCHA

It came up as a theoretical hypothesis: replace Cloudflare Turnstile with another CAPTCHA that has documented SRI support.

Turnstile works, is stable, integrates natively with the rest of the Cloudflare infrastructure, and is free. Replacing it would introduce regression risk on the contact form (the site’s only lead-capture channel), integration effort, and potential cost — all to address a cosmetic problem in the SecurityScorecard score. It is throwing out the house to adjust the picture frame.

In security, knowing what not to do is often harder — and more valuable — than knowing what to do. Every remediation has a cost: time, operational complexity, and regression risk. Weighing that cost against the real benefit is executive judgement.

Outcome

The next SecurityScorecard algorithm recalibration, scheduled for 20 May 2026, projects the score at 99.

Transferable principles

Five principles at play in this intervention, transferable to more complex corporate contexts:

1. Diagnose before remediating. Cross-reference sources. A single tool tells a partial story. Fifteen minutes of diagnosis spares hours of misguided remediation.
2. Edge-first when possible. Solving at the edge (Cloudflare, WAF, reverse proxy) is often cheaper, more reversible, and more independent than touching the application. In corporate SAP environments, the equivalent principle is to solve in the SAP Cloud Connector, gateway, or middleware layers whenever possible, rather than modifying the core system.
3. ROI per action, not per report. Every finding has a remediation cost and an expected benefit. Weighing both before acting is elementary — and rarely done systematically.
4. Document the decisions NOT to act. Decisions not to act are the first to be forgotten — and the first to be questioned in audit months later. Documenting the justification at the moment of the decision avoids re-litigating the same analysis again and again.
5. Accept strategic imperfection. 97 out of 100 with zero complexity is often preferable to 100 out of 100 with permanent operational complexity. The difference is not in the score — it is in the accumulated cost of maintaining it.

Closing notes

A SecurityScorecard A grade is not an end in itself — it is one indicator among many, with its methodology, its biases, and its blind spots. The real value of this campaign is not in the 13 points gained: it is in the evaluation discipline applied to each action, in the cross-source diagnosis, and in documenting the decisions — including the decisions not to act.

Consistency requires that the site itself reflects the standards advised to clients — and that those standards be achieved with the same ROI discipline recommended in any other context.

In senior IT consulting, this discipline is often more valuable than isolated technical depth. It is what separates a competent intervention from a genuinely useful one.

This case reflects the state of the infrastructure and tooling in May 2026. SecurityScorecard, Cloudflare, and the other components evolve continuously; the decisions described should be reviewed in light of the current context at any given moment.

The decisions described were made for a specific case — own site, low-risk context, with no sectoral regulatory requirements. In corporate environments subject to specific regulation (PCI-DSS, HIPAA, NIS2, DORA, among others), the ROI calculation includes additional factors and some decisions may differ.

Contact →