To be completely honest, my history with WordPress goes way back. I’ve been running a self-hosted WordPress blog since I was a freshman in high school. Ever since those early days, whenever I needed a place to write, tinker with themes, or break things with plugins, I always ended up returning to this classic CMS.
Recently, I had an itch to try a more modern approach: turning my setup into a headless WordPress. The plan was to migrate the frontend over to a serverless platform while keeping the main WordPress instance on traditional web hosting purely as a content backend. I’ve known that WordPress has an integrated REST API for a long time, but as with most side projects, I only just got around to actually testing it out.
Interestingly enough, when I started consuming the API endpoints, I stumbled upon a surprising default behavior: the REST API is open to the public and accessible by anyone without authentication. As a quick sanity check, I tried fetching all articles from a large tech media blog and sure enough, the raw article contents came straight back in clean, full JSON format.
While that’s undeniably great for developer convenience, what I quickly realized is that it poses a few questionable risks:
- Automated content scraping: Anyone can easily fetch your entire article library via API endpoints, spin up a clone site, and apply for advertising programs without writing a single paragraph of original content.
- Spam backlink issues: Scrapers can harvest your content to build low-quality mirror sites. If those articles contain your internal links, search engines might start associating your domain with spammy backlink networks.
I strongly agree with the points made in Crowd Favorite’s article on avoiding unintended exposure from the WordPress REST API endpoints like these really should be restricted and protected behind authentication by default. Sure, there are plenty of plugins available to disable the API, but it still makes me wonder: why isn’t this feature disabled out of the box, or at least locked behind a login layer by default?
This little discovery left me feeling a bit conflicted. Combined with WordPress’s long history of plugin-related CVE vulnerabilities, I’ve been feeling the urge to gradually move away from the platform altogether. I even looked into a couple of alternative Headless CMS options:
- Strapi: Feature-rich and developer-friendly, but it requires at least 2GB of RAM to run smoothly. For a budget cPanel host running Node.js or a small VPS setup, that feels a bit too resource-heavy.
- Emdash: Looks promising, but it’s built around Astro. Meanwhile, my frontend was already completely built using Nuxt.
Looking ahead, I’m still weighing my options whether I should stick with WordPress as a headless backend (with its API endpoints strictly locked down) or start planning a total migration to a lighter, modern CMS. If nothing else, this little experiment was a good reminder that features designed for ultimate convenience often come with security trade-offs you have to patch yourself.