From Audit Findings to Low-Risk Fixes on a Managed WordPress Site

A routine security review exposed several gaps on a live WordPress site hosted on WP Engine, including a missing security.txt file, missing HTTP security headers, and broader concerns around admin exposure. The challenge was not just fixing the findings, but doing so in a way that avoided downtime, avoided unnecessary plugins, and respected the realities of an already-running client environment.

The problem

The site had landed in the familiar middle ground that many long-running WordPress projects occupy: stable enough to stay online, but missing a few modern security controls that external audits now expect to see. The audit highlighted missing security.txt, missing headers such as Permissions-Policy, Referrer-Policy, Strict-Transport-Security, and X-Content-Type-Options, and recommendations around access restrictions for admin-related paths. None of these items existed in isolation; together, they raised the real question every developer has to answer on production work: how to improve security without creating avoidable breakage.

Why this was tricky

On paper, the fixes looked simple. In practice, applying security controls to a live managed-hosting setup can be risky when plugins, third-party scripts, old content, and operational habits have built up over time. A strong policy applied too aggressively can block legitimate assets, disrupt logins, or create support noise for a site that had otherwise been functioning normally.

That meant the job was not “apply every recommendation immediately.” The job was to split findings into safe wins, cautious changes, and deferred items that required testing or approval.

The first fix: security.txt

The first step was to publish a valid security.txt file at the standard discovery path expected by security tooling. The useful lesson here is that security.txt does not need to be overengineered from day one. Under RFC 9116, only Contact and Expires are required; fields such as Policy, Encryption, and Acknowledgments are optional.

That matters because many organizations do not yet have a formal vulnerability disclosure program, a public policy page, or a dedicated PGP key. In that situation, the right move is to publish a minimal but accurate file rather than a polished-looking file full of placeholders nobody will maintain.

A minimal version looked like this:

Contact: mailto:[e-mail]
Expires: 2027-03-31T23:59:59Z

That solved the audit finding while keeping the implementation honest and maintainable.

The second fix: security headers in the right place

The next step was to add the missing HTTP security headers, but not through another WordPress plugin. On WP Engine, platform-level configuration through Web Rules is a cleaner and more supportable place to manage response headers than patching them into the application layer.

This distinction matters. A plugin-based fix may technically work, but it also adds more moving parts to the same WordPress stack that is already being audited for risk and complexity. Using the hosting platform for headers reduces that dependency footprint and makes the behavior easier to reason about across environments.

The rollout focused first on the safer headers:

• X-Content-Type-Options: nosniff to reduce MIME-type sniffing risk.
• Referrer-Policy: strict-origin-when-cross-origin to improve privacy without usually breaking normal behavior.
• A conservative Permissions-Policy based on what the site actually needed, instead of a copied policy template.

The fix that needed caution

Strict-Transport-Security was not treated as a copy-paste checkbox. HSTS is valuable, but it changes browser behavior in a sticky way by telling clients to use HTTPS only for a defined period, which means a bad rollout can have consequences beyond a single deploy.

That is why the safer approach was to stage HSTS behind an HTTPS readiness check instead of enabling an aggressive policy immediately. If any assets, legacy links, or integrations still depend on http://, turning on HSTS too early can break parts of the site experience rather than harden it cleanly.

What actually solved the problem

The real solution was not one header or one file. The solution was a triage model:

• Implement immediately what is low-risk and clearly beneficial.
• Test carefully anything that can affect site behavior across browsers or subdomains.
• Defer controls that require stakeholder approval, process change, or operational support.

That approach turned a potentially messy audit response into a practical remediation plan. It also kept the work aligned with the reality of WordPress development: good security changes are the ones that survive production, not just the ones that look impressive in a checklist.

What this is really about

Security work on WordPress often gets framed as a plugin hunt or a list of hardening tips. In production, it is usually a prioritization problem instead: deciding what belongs in hosting, what belongs in the app, what needs testing, and what should wait for process maturity.

That is the more useful lesson from this kind of task. The best security fix is often not the most aggressive one; it is the one that improves the posture of the site while keeping risk, complexity, and maintenance load under control.