Security on a public site: what you actually have to own

A public site is interesting to attackers because it is easy. Not because you are interesting. Automated scans look for known plugin holes, default admin paths, open .git folders and keys someone committed two years ago. They do not need to know you. They need a site still running what everyone else has patched.

When it goes wrong on a marketing site, it is rarely a cinematic break-in. It is a spam page in your CMS, a redirect to a shop you do not own, or a script in a theme header that steals forms. SEO dies afterwards — Google is quick to mark a compromised site, and slow to forget it. That is also why security and SEO sit together here, without being the same thing.

Teams overreact or underreact. Over: a WAF subscription, three plugins and a feeling that the topic is off the table. Under: "we are just a brochure." The brochure has a login, a contact-form endpoint and often a preview that shows the next campaign. That is enough. You do not need to be a bank to have a door someone will try.

This is not a pentest report and not a promise that you are "secure". It is the engineering conversation you should have before you buy the next plugin: what can a stranger do to this site in an afternoon, and what have you put in the way?

Do not start with nation-state. Start with what happens to sites like yours. One: known vulnerabilities in CMS, theme and plugins — especially WordPress, especially things you no longer use but have not turned off. Two: credential stuffing against /wp-admin, /login, /studio or the CMS you forgot to put 2FA on. Three: secrets in git, in a screenshot, in a Vercel log, in an old .env on a staff laptop.

Four: open previews and staging with real data and weak auth. Five: a contact-form endpoint with no rate limit that becomes a spam cannon or a place to try injection. Six: an open redirect or an old subdomain pointing at a bucket you no longer own. That is the list. It is boring. It is also the one that takes sites.

What you typically should not start with: writing a forty-page policy, buying an overlay that promises a "malware scan", or asking for a full pentest of a brochure before you have turned unused plugins off. Pentest is right when you have something to test — a login, a checkout, an API. First: close the doors you can see yourselves.

The GDPR conversation is a different one. That is about what you send, and whether the user said yes. This one is about what a stranger can do, regardless of consent. A site can have a tidy cookie banner and still an open admin. The two checklists should not be mixed. They should both be done.

HTTPS is the floor. HSTS tells the browser it must not go back to HTTP. Without HSTS a network you do not control can still try to downgrade the first hop. Set it when you are sure you do not have an older HTTP-only endpoint you depend on. That is a one-line header choice, not a project.

Content-Security-Policy is what limits which scripts and embeds the page may load. An honest CSP is tight and breaks when someone drops in a new pixel. That is the point. A CSP with 'unsafe-inline' and a dozen wildcard domains is a badge. Start with default-src 'self', allow what you actually use, and run Report-Only for a week before you enforce. If you cannot list your script domains, you have a different problem — the same inventory the GDPR post asks for.

Referrer-Policy, X-Content-Type-Options, Permissions-Policy and a frame-ancestors that does not allow you to be iframed on a foreign site are next. None of them make you interesting at a conference. All of them remove a whole class of "someone embedded us and stole a click". On Next.js you set them in next.config or at your edge. On Cloudflare you can set them there. On WordPress the theme or the server has to do it — a plugin that promises "all the headers" is fine if you check that they are actually sent.

The TLS certificate should renew itself. If a human has to remember it, it will expire on a Saturday. Let's Encrypt via your host, or the cert management your edge already has, is the right answer. A screenshot of a padlock icon on a slide is the wrong one.

On WordPress the typical break is the plugin and theme surface. You have an ecosystem that is easy to extend and easy to forget. Security here is hygiene: fewer plugins, automatic updates you actually watch, a theme you can explain, and an admin that is not open to the internet's credential lists. A "security plugin" can help hide /wp-admin and block some paths. It cannot save a theme that no longer gets patches.

On Next.js and a hosted CMS the typical break is secrets and preview. A NEXT_PUBLIC_ variable that should not have been public. A preview URL with no auth. A server action that trusts what the browser sends. Deploy keys in a GitHub Actions log. You have fewer plugins and more places where you are the platform. That is not safer by itself. It is safer if you treat env and preview as production.

Both stacks owe you the same thing on the outside: HTTPS, headers, a form endpoint that is not an open hose, and an admin you can defend. Both can sit behind Cloudflare and get a WAF and bot controls. The WAF is a net. It is useful. It is not an excuse to run a CMS you do not update, or a preview you share in Slack without login.

If you are considering moving from WordPress to Next.js for security reasons alone, be honest: you are moving the place the boring failures can sit. You remove the plugin surface. You get the env and pipeline surface. Move if you also have other reasons — editing, performance, SEO control. Do not move because a slide said Jamstack is secure. Static files are hard to infect. Your build and your CMS are not.