Assume that one of your developers builds a custom REST endpoint so that your client’s mobile app can pull product data straight from WordPress. It works on the first try, everyone is happy, and the project ships. Nobody circles back to check who else can reach that endpoint. Eight months later, a routine security scan turns up the same endpoint quietly returning full customer records to anyone who knew the URL, no login required.
That is not a rare story. It is closer to the default outcome for how most WordPress developers treat APIs, custom or otherwise.
Why WordPress developers cannot treat this as someone else’s problem
WordPress runs on both the REST API and, for older integrations, XML-RPC, and either one becomes part of your site’s attack surface the moment it is active, whether or not you personally wrote a line of code behind it. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% jump from the year before, and found plugins responsible for 91% of them. Themes and custom functionality built on top of those plugins inherit the exposure.
The platform itself is not unusually broken. WordPress ships with enormous flexibility, and flexibility without discipline is exactly where API vulnerabilities like to live, especially on custom endpoints that never went through a formal review because they only took an afternoon to build. Here is where that discipline actually needs to show up.
1. Authenticate every endpoint that touches real data
The WordPress REST API assumes public access unless you tell it otherwise. A custom endpoint built quickly, for an internal tool or a one-off integration, often skips authentication entirely because the deadline was tight and the endpoint felt harmless at the time. Nonces work for logged-in browser sessions.
Application passwords, introduced in WordPress 5.6, work better for external services and scripts, since they can be issued per integration and revoked individually without touching a user’s main login. Treat every custom route as public until proven otherwise, because that is exactly how an unauthenticated scanner will treat it too.
2. Force encryption on everything moving through the API
An API call carrying customer data over plain HTTP is readable by anyone positioned between the client and your server, on public WiFi, at a compromised router nearly anywhere along the path. TLS must not be considered optional for any endpoint handling authentication tokens, personal details, or payment-adjacent information.
A Cloud Security API approach treats every API the same way it treats cloud infrastructure generally, as a border that needs enforcement rather than a convenience that happens to work. Mixed content warnings and expired certificates are usually the first visible sign that this got skipped somewhere in the stack.
3. Validate and sanitize everything the API receives
Every parameter a request sends in is an opportunity for the person sending it and for whoever might be forging it. WordPress core provides sanitization functions built specifically for this, and skipping them on a custom endpoint because the input is assumed to always arrive clean is how a text field ends up accepting a database command instead of a product name.
Validate types, lengths, and formats on the way in, and sanitize again on the way out if that same data ever gets displayed back to a user. A single unchecked field is often the only gap an attacker actually needs, and it rarely announces itself until someone finds it on purpose.
4. Scope every API key to the smallest job it has
A key or application password generated with full administrative rights, for a task that only ever needs to read product listings, is a liability sitting in someone’s environment file waiting to matter. If that integration only needs read access to one custom post type, that is the entire scope it should get. This becomes the difference between a leaked key exposing one dataset and a leaked key handing over the whole site. Revoke keys the moment an integration gets retired, not the next time someone happens to notice it still active in the credentials list.
This habit tends to erode fastest on small teams, where one developer wears every hat and issuing a narrowly scoped key feels like an extra step nobody has time for during a launch week. It is worth the extra step anyway. A dashboard listing every active key, what it can touch, and when it was last used takes an afternoon to build once and saves a much longer afternoon later, spent figuring out which of a dozen forgotten keys an attacker actually used.
5. Rate limit before someone else rate limits you
An endpoint with no request limit becomes a free tool for anyone running an automated script, whether they are scraping content, brute-forcing a login form, or hammering a search function until the server buckles. Most managed WordPress hosts offer some server-level throttling, but it rarely covers custom endpoints specifically.
A plugin-level rate limiter, or a rule set at the reverse proxy, gives you control over exactly which routes need tighter limits and which can stay open. A contact form getting hit two hundred times a minute from one IP address is not organic traffic, and your API should be able to say so.
6. Turn off what you are not actively using
The default WordPress REST API exposes a user endpoint at /wp-json/wp/v2/users that lists every author’s username and ID, a small convenience for developers that also hands attackers a ready-made list of accounts to target with password guesses. XML-RPC, still enabled by default on many installs, gets abused constantly for brute-force attempts and amplification attacks, despite most sites never using it for anything at all.
Our own breakdown of why WordPress feels hard to manage covers this same pattern elsewhere on the platform, plugins and settings nobody remembers enabling, sitting active because disabling them was never assigned to anyone specifically. Auditing active endpoints once a quarter catches most of this before it becomes a problem, and it takes less time than most developers assume once it becomes a habit instead of a special project.
7. Patch fast, and actually watch what is happening
Patchstack’s same 2026 report found a weighted median of just five hours between a vulnerability’s public disclosure and its first mass exploitation attempt, with a fifth of tracked vulnerabilities exploited within six hours. A monthly update schedule is not fast enough against numbers like that, particularly for anything touching your API layer directly.
Logging API requests, and actually reviewing that log rather than letting it accumulate untouched, is what turns a five-hour exploitation window into a caught attempt instead of a headline. Our guide to keeping a WordPress site secure day to day walks through the monitoring habits that make this realistic for a small team without a dedicated security hire.
What actually separates the sites that get hit
Every WordPress site eventually exposes an API of some kind, whether that is core’s own REST endpoints, a plugin’s integration layer, or a custom route built for one client’s specific request. The sites that stay out of the breach reports are rarely the ones with the most expensive security tooling. They are the ones where someone treated each new endpoint as a door that needed a lock fitted before it opened, not after.
That client’s mobile app endpoint from the opening story still works fine today, once someone finally added authentication to it. The fix took twenty minutes. Finding out it was needed took eight months.