Acta AI
June 1, 2026
API data breaches rose 80% year-over-year in 2024, and the volume of records exposed grew 214% (Source: FireTail, 2024). The WordPress REST API is a powerful publishing tool. It is also an open door if you configure it carelessly.
Most small business owners who set up REST API publishing make the same three mistakes: they use their main admin password, they leave unauthenticated endpoints exposed, and they never think about what happens when credentials leak. This article walks through exactly how to avoid all three, based on firsthand experience building WordPress publishing integrations for consulting clients. No coding background required.
As of 2025, 11,334 new vulnerabilities were discovered in the WordPress ecosystem, a 42% increase over the prior year (Source: WebOptimo, 2026).
TL;DR: The WordPress REST API lets external tools publish content to your site automatically, but its default settings leave you exposed. Secure it by generating dedicated app passwords for each tool, restricting sensitive endpoints like
/wp-json/wp/v2/users, and installing an activity log plugin before you need one. As of 2025, the threat environment around WordPress has never been more active.
The WordPress REST API is a built-in interface that lets external tools create, edit, and publish content on your site without logging into the dashboard. For publishers and e-commerce store owners, it means you can automate blog posts, connect third-party tools, and build content pipelines. The catch is that it also exposes your site to outside requests by default.
Every WordPress install ships with REST API endpoints active out of the box. Most site owners have no idea. The API handles posts, pages, media uploads, categories, tags, and SEO plugin fields from Yoast SEO and RankMath. It is the backbone of any automated publishing workflow, and it is running on your site whether you use it intentionally or not.
The REST API was designed for flexibility, not security-first. It assumes you will add authentication and access controls yourself. That assumption trips up a lot of people.
Akamai's 2026 survey of 310 global commerce leaders found that over 80% reported at least one API-related security incident in the prior 12 months (Source: Akamai, 2026). E-commerce sites built on WordPress are a specific target. Knowing the API exists is step one.
If you log into your WordPress dashboard and write posts by hand, you are not using the REST API directly. But any third-party tool, scheduling plugin, or autoblogging platform you connect to your site almost certainly is. Understanding what it does helps you make smarter decisions about which tools you authorize.
WordPress app passwords, introduced in version 5.6, let you generate a unique credential for each external tool without sharing your main login password. Each app password can be revoked independently. Setting one up takes under three minutes and is the single most important security step before connecting any publishing tool to your site.
Here is the exact process:
Your verifiable output: a unique credential stored in your password manager, separate from your main login. If you cannot find the Application Passwords section, your site is likely running on HTTP rather than HTTPS.
Use one app password per tool or integration. If one credential leaks, you revoke only that one without disrupting everything else.
The limitation worth knowing: app passwords require HTTPS. If your site runs on plain HTTP, WordPress disables the feature entirely. This is not a bug. It is intentional, which means you need an SSL certificate installed before any of this works.
I learned this the hard way with a consulting client. They had connected a publishing integration using their main admin credentials inside a third-party tool's settings panel. Everything ran fine until they updated their password for an unrelated reason, and the entire content pipeline broke silently with no error message. After we rebuilt it with a dedicated app password, the fix took five minutes. The lesson took a failed deployment to learn. One credential per tool is not optional. It is the architecture.
By default, the WordPress REST API exposes user data, post content, and plugin-registered endpoints to unauthenticated requests. For a publishing workflow, you only need a small subset of those endpoints. Restricting everything else cuts your attack surface without breaking your content pipeline, and you can do this without writing a single line of code.
The /wp-json/wp/v2/users endpoint is the most commonly abused. It returns usernames publicly, which attackers use to target login pages with credential-stuffing tools. A security plugin like Wordfence handles this with a toggle in its settings. No code required.
92% of WordPress breaches in 2025 came from plugins and themes, not core WordPress itself (Source: WebOptimo, 2026). Every plugin you install may register its own REST API routes. Open your browser and visit yoursite.com/wp-json/ to see a full list of active endpoints. Anything you do not recognize is worth investigating.
29% of all web attacks in 2023 targeted APIs directly, with the commerce sector accounting for 44% of those incidents (Source: Akamai, 2024). If you run a WooCommerce store alongside your blog, your REST API exposure is higher than average.
This breaks down when you start blanket-blocking unauthenticated API access. Some page builders and WooCommerce extensions rely on public REST endpoints to function. Restricting them too aggressively can break checkout flows or dynamic content rendering. Always test changes on a staging site first. Staging is not optional here.
Key Takeaway: Restrict the
/wp-json/wp/v2/usersendpoint immediately. It exposes admin usernames to anyone who visits the URL, and it is the first place automated scanners check.
Disabling the REST API completely breaks the WordPress block editor, many plugins, and any publishing tool you have connected. The smarter move is to require authentication for sensitive endpoints rather than shutting everything off. Selective restriction gives you real security without sacrificing functionality.
If an app password leaks, revoke it immediately from Users → Profile → Application Passwords, then generate a replacement. After that, audit your recent post revisions and media library for anything you did not publish yourself. A compromised API credential can create posts, upload files, and modify existing content silently, and WordPress will not alert you unless you have logging set up.
WordPress logs REST API activity only if you have a plugin like WP Activity Log installed. Without it, you have no visibility into what an attacker did with your credentials. Install one before you need it. This is the step most site owners skip.
Revoking the app password stops future access but does not undo changes already made. Check post statuses, scheduled content, and any newly created user accounts. Attackers who gain API access sometimes create a secondary admin account as a backdoor before the primary credential gets revoked.
There is also a subtler problem specific to AI-powered publishing workflows. DALL-E and similar image generation tools produce URLs that expire within hours. In an early version of a publishing integration I built, I stored the raw DALL-E URL in the featured image field instead of uploading the file to WordPress media first. Three posts went live with broken featured images because the URLs expired before anyone noticed. The fix was to download the image file and push it through the REST API media endpoint before creating the post.
That sequence is now the default in every workflow I build. It also closes a secondary vulnerability: expiring URLs give an attacker a shorter window to intercept image content, but the image loss is permanent if you have not uploaded it locally first.
API data breaches rose 80% year-over-year in 2024, with records breached growing 214% (Source: FireTail, 2024). Speed of response matters more than most site owners realize.
Yes. Several platforms connect to the WordPress REST API without requiring any coding on your part. You authenticate once using an app password, and the tool handles post creation, media uploads, category assignment, and SEO field population automatically. The tradeoff: you are trusting a third-party service with your site credentials, so choose one with a documented security record and clear data handling policies.
When evaluating a no-code publishing tool, check whether it supports Yoast SEO or RankMath field injection. Many tools create posts but leave meta titles and descriptions blank, which undermines your SEO effort entirely. A post without a meta title is one that search engines will interpret on their own terms. Usually not in your favor.
Acta AI handles WordPress REST API publishing with app password authentication, Yoast and RankMath SEO field injection, and media library uploads built into the default workflow. You connect your site once, and the content pipeline manages the rest automatically.
Most site owners treat API security as a one-time setup task. They generate an app password, connect their tool, and never revisit it. The actual risk is ongoing. App passwords do not expire automatically. A credential you created two years ago for a tool you no longer use is still active unless you manually revoke it. Go to Users → Profile → Application Passwords right now and delete anything you do not recognize or no longer need.
The second common mistake is assuming that because the REST API "just works," it is safe by default. It is not. Permissive by default is a very different thing from secure by default.
This guidance assumes your WordPress site runs a current version with HTTPS enabled and plugins kept up to date. If any of those conditions are missing, the picture changes considerably.
App passwords do not exist on WordPress installs older than version 5.6. Endpoint restriction plugins behave differently across hosting environments, and some managed WordPress hosts block REST API customization at the server level. In those cases, contact your host directly before making any changes.
Although the steps above work for most standard WordPress setups, multisite installations and headless WordPress configurations introduce additional complexity around authentication scope and endpoint inheritance. Those environments need a developer review, not a plugin toggle.
For a broader look at how automated publishing fits into a content strategy, visit our blog for related guides on WordPress and Shopify publishing workflows.