For cybersecurity companies
Keep WordPress for editing. Separate the public site.
Your marketing team needs a familiar editor. Your security team needs a public site they can inspect. We keep WordPress for editing and build the public website in Astro. We move WordPress administration off the public domain and document the code, headers, and deployment setup for your security team to review.
What we see
What to review on your marketing site
Plugins and patching
Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 46% unpatched at disclosure, with a median five hours to first exploit. The review starts with the software your public site runs and who maintains it.
A login page on the public internet
Wordfence blocked 55 billion password attacks against WordPress sites in 2024. We move the WordPress login off your public domain and behind your identity provider.
WordPress core updates
WordPress core itself was exploited in the wild twice in 2026: WP2Shell in July and Click2Shell in September. Both were patched quickly. Both sat on public hosts for the hours before the patch.
Headers and reporting contacts
We check the Content Security Policy, HSTS, and security.txt file as part of the rebuild, with configuration and reports your security team can review.
The standards that apply
Security controls your team can review
We document what runs on the public site, how the editor is protected, and how forms and third-party scripts are handled.
Shrink the attack surface
OWASP defines the attack surface as every path for data and commands into and out of an application, and says to reduce it by turning off what is not used. Serving the public site as pre-built files removes PHP, the database, and the admin from the public host. Sucuri notes that a decoupled deployment behind a CDN shrinks direct exposure of the CMS core.
Source: OWASP, Attack Surface Analysis Cheat Sheet. Checked .
A Content Security Policy and strict headers
A Content Security Policy restricts what code the browser will run for your site and adds a layer of protection against cross-site scripting. We configure HSTS, a Permissions-Policy, and Subresource Integrity where third-party scripts support it, then check the result against MDN's HTTP Observatory.
Source: MDN Web Docs, Content Security Policy. Checked .
A security.txt file
RFC 9116 defines a file at /.well-known/security.txt with a contact and an expiry so researchers know where to send a report. We include it in the rebuild.
Source: RFC Editor, RFC 9116: a file format to aid in security vulnerability disclosure. Checked .
A documented setup for your auditor
WordPress runs as the editor on a separate host behind your identity provider. Your auditor determines SOC 2 or ISO 27001 scope based on the systems and data involved. We document the hosting, access controls, and data flows for that review.
Source: StrongDM, How to define the scope of a SOC 2 report. Checked .
Stays the same
What your team keeps
- Marketing and content teams keep editing in WordPress, behind your single sign-on
- Blog, resources, case studies, and product pages stay in the fields your team uses
- Your marketing automation and forms keep their integrations through embeds or a small relay
- Your SEO plugin data and every existing URL carry over
Changes
What the rebuild replaces
- The public site is pre-built HTML on a content delivery network with no PHP, no database, and no login page
- WordPress moves off the public domain to a private host that only the front end and your editors can reach
- A Content Security Policy, HSTS, Permissions-Policy, and security.txt ship with the site, with Subresource Integrity where supported
- Plugins used only to display the public site are removed
How it runs
How we rebuild your security company's site
Threat model the site
We list what the site accepts from visitors, such as forms, search, and chat, what it loads from third parties, and what an attacker would want: defacement, credential theft, or a foothold in your marketing stack.
Build with security controls in place
We build Astro templates with a Content Security Policy, use Subresource Integrity where third-party scripts support it, and route forms through a small server endpoint with rate limits.
Make the editor private
WordPress goes to a private host or subdomain behind your identity provider, and the public front end reads content through an authenticated connection.
Document the setup
A header report from MDN's HTTP Observatory, the security.txt, the redirect map, and documentation your security team can review, keep, and re-run.
Questions
What cybersecurity teams ask first
Short answers here. The full picture comes from a review of your site.
Why not just harden WordPress?
You can, and many teams do. A rebuild changes which software runs on the public host: WordPress, PHP, and the database move behind the editor's access controls. WordPress still needs maintenance there. Your security team can review whether that separation suits your requirements.
Does a static site have no attack surface?
It has a smaller one. Forms, search, and third-party scripts are still paths in, and we treat them that way: server-side validation, rate limits, a strict Content Security Policy, and integrity hashes on external scripts. The difference is that the CMS and the admin are no longer reachable from the public domain.
Our security team wants to review the build. Can they?
Yes. You get the repository, header configuration, Content Security Policy, and deployment setup so your team can inspect how the site works.
What about our chat widget and marketing automation?
They can stay, pinned with Subresource Integrity where the vendor supports it and named explicitly in the Content Security Policy. We list every third-party script in the project plan so your team can decide which to keep.
Is this in scope for our SOC 2?
Your auditor determines the scope based on the systems and data involved. We document where WordPress runs, who can access it, and how forms and data are handled so your auditor can review the setup.
Sources
Tell us what your website needs.
Send us your website address and what you’d like to change. We’ll take a look and reply by email.