Looking for more on Security? This collection on the Emdash Kits blog brings together related articles, guides, and insights. Browse all 8 posts below.
Every login-gated page worked perfectly on the live site and failed silently on localhost during testing — the session cookie had secure hardcoded to true, and browsers never send a Secure cookie over plain HTTP.
The gtag.js snippet was installed correctly and the page loaded fine, but GA4's real-time report stayed empty — because the CMS's Content-Security-Policy was silently blocking every request to Google's domains.
Media uploads worked fine right after uploading, then vanished the next deploy — plus a related gotcha from the same migration: CSRF/origin checks and signed URLs resolving wrong behind a reverse proxy.
Clicking "Sign in with GitHub" in the admin panel requested a URL that didn't exist — the admin's own client-side router was treating an external API link as one of its own internal routes.
A failed GitHub sign-in only ever showed a generic schema-validation error in the logs — GitHub's actual reason (a bad code, wrong client credentials) was being silently discarded.
Every save on one specific article failed with a bare 403 Forbidden that had nothing to do with the CMS — a hosting-provider WAF was anomaly-scoring the request body and blocking it before it ever reached the app.
Over 11,000 new vulnerabilities hit the WordPress ecosystem in a year — 91% of them from plugins. A clear-eyed look at why WordPress security is structurally hard, and what headless does differently.
No passwords to leak (login is passkey-based), plugins that can't touch the network unless they explicitly declare and get approved for it, and secrets encrypted at rest with a key you control. Here's what's actually built in, mechanism by mechanism.