TL;DR — Saving a specific, code-heavy article in the CMS admin returned a bare, plain-text 403 Forbidden. The post loaded and read fine; only saving it failed. Nothing was wrong with permissions or the CMS itself — the site's hosting-provider CDN/WAF was anomaly-scoring the request body and blocking it at the edge, before authentication was even checked.

How to recognize this variant of "save keeps failing"

• The response body is plain text (e.g. just the word "Forbidden"), not your CMS's normal JSON error shape.
• The Server response header names the CDN/hosting provider, not your app.
• The same post saves fine with trivial content; other posts save fine too — only content-heavy saves die.

The diagnostic

Replay the same save payload without a valid session:

curl -i -X PUT https://your-site.com/_emdash/api/content/posts/<id> -d @payload.json
# 401 -> passed the WAF, hit your app's own auth check (not a WAF issue)
# 403 (plain text, no app error shape) -> blocked before auth ever ran

Root cause

Hosting-provider CDNs/WAFs (e.g. Hostinger's hcdn, Cloudflare) score request bodies for injection-looking patterns. A save request ships the entire article body along with whatever field changed. Code-heavy content — many JS template literals (${...}) or piped shell one-liners in code blocks — adds to that anomaly score, and enough of it in one payload crosses the WAF's threshold.

Fix options

• Rewrite the offending article's code blocks to avoid the triggering patterns — string concatenation instead of template literals, no shell pipes — then re-verify with the same unauthenticated probe.
• For a durable fix, whitelist the CMS admin path (e.g. /_emdash/*) in the hosting panel's WAF rules.
• If a save still won't go through no matter how the content is rewritten, writing the specific field directly via a DB script is a legitimate one-off escape hatch — confirm with whoever owns the content first, since it skips the app's own validation.

Variant: a single field silently fails to save, with no error shown

A subtler version of this bug does not throw any 403 at all. Uploading a featured image through the post editor can successfully register the media file and set the postseo_image field (used for Open Graph and social-card previews), while the separate write that links that same image to the postfeatured_image field silently drops. Same root cause, same WAF anomaly scoring, just tripped on a different write inside the same save sequence. Nothing in the admin UI flags it as a failure.

How to recognize this variant

• The social/Open Graph preview for the post looks correct, but the featured-image thumbnail is missing in the admin post list, and there is no hero image at the top of the published post.
• Comparing the post row against its SEO metadata row directly in the database shows the media file registered under seo_image, while featured_image on the same post is empty.

Fix: a small reusable script beats a one-off SQL patch

The one-off DB-script escape hatch above is fine for a single incident, but a field that keeps silently dropping across multiple articles is worth turning into a small reusable script instead of hand-writing the same lookup and update again each time it recurs. A script that resolves the post by slug, finds the already-uploaded media row, and writes that field in its exact JSON shape to both the post row and its revision data keeps the admin UI and public page in sync, and can fall back to whatever is already set in seo_image when no image is specified explicitly.

node scripts/set-featured-image.mjs --slug=your-post-slug

Lessons learned

• A bare 403 with a non-app-shaped body, especially reproducible unauthenticated, is a hosting-layer signal — don't waste time auditing CMS permissions code first.
• Writing technical articles about your own stack means the article body itself can trip this; write code samples defensively (concatenation, no pipes) as a habit, not just as a reaction.
• A save that reports success can still have silently dropped one field. Cross-check a value mirrored elsewhere (like seo_image) against the field that looks missing, rather than assuming a clean save means every field made it through.