Yes, CMS content previews can leak through a public API when an endpoint returns unpublished material without strong authorization. A public API is a web address that provides data without requiring a login or valid access token. The risk depends on what the endpoint exposes, not simply on whether the CMS has an API. A properly configured API can show published content while protecting drafts, scheduled posts, private pages, and preview-only revisions.
Table of Contents
- What Actually Leaks?
- Why Do Preview URLs Become Public?
- Which Content and Sites Face the Greatest Risk?
- How Can You Check for Exposure?
- How Should You Fix the Problem?
What Actually Leaks?
A preview leak occurs when someone can retrieve content intended only for editors or approved reviewers. The response might include a complete draft, revised text, private metadata, author notes, unpublished images, or internal URLs. The content may appear in a REST API response, a JSON:API document, a GraphQL query, or a custom preview endpoint.
Sometimes the page itself remains hidden while its underlying JSON remains available. A public response can also reveal more than the visible article. Fields such as publication status, scheduled dates, revision identifiers, author email addresses, or internal taxonomy terms may expose useful information even when the full draft is not returned.
Why Do Preview URLs Become Public?
Preview systems often rely on a token embedded in a URL. If the token is predictable, long-lived, logged in analytics systems, or forwarded to the wrong person, another visitor may reuse it. Caching creates another failure point. A CDN, reverse proxy, or browser cache can store a preview response and serve it to people who do not have permission.
Incorrect cache keys can mix authenticated and unauthenticated responses. cms extensions also change the security model. In WordPress, the standard REST API generally protects drafts through authentication, but custom endpoints and plugins can expose them accidentally. drupal sites using JSON:API or custom routes must likewise apply the correct entity and route permissions.
Which Content and Sites Face the Greatest Risk?
The highest-risk content usually includes drafts, scheduled campaigns, embargoed announcements, private landing pages, and revisions containing sensitive business information. Marketing teams should also protect unpublished ad copy, product launches, pricing changes, and tracking details. Headless CMS installations deserve extra attention because the front end and CMS communicate through APIs by design. Developers may make an endpoint public for convenience, then rely on the front end to hide records.
That approach does not protect the data; anyone who can call the endpoint can inspect its response. A public API is not automatically dangerous. Publishing article titles, excerpts, images, and other deliberately public fields is normal. The problem begins when access control treats "not visible in the site interface" as equivalent to "not accessible over the network.".
How Can You Check for Exposure?
Test from a signed-out browser or a private browsing window. Do not use an editor's session, because an authenticated response can make a protected endpoint look public.
Check the API response for unpublished records and sensitive fields, not only for a visible preview page. Useful checks include: A test should use harmless content whenever possible. If a public request returns a real confidential draft, stop broad testing, preserve the request details, and notify the site owner or security contact.
- Request common collection and detail endpoints without cookies or authorization headers.
- Search responses for draft, scheduled, private, pending, or revision records.
- Test preview links after removing cookies, changing browsers, and waiting for the intended expiration.
- Inspect CDN and proxy headers for public caching of authenticated responses.
- Verify that changing an ID, slug, or query parameter does not reveal another record.
How Should You Fix the Problem?
Enforce authorization where the API serves data. Check the user's role, the content's publication state, and the specific preview token before returning unpublished fields. Hiding records in the front-end application is not a substitute for these checks. Use short-lived, unpredictable preview tokens tied to the intended content and, where practical, to a user or review session. Revoke tokens when content changes or the review period ends.
Avoid placing sensitive information in query strings when logs or analytics tools may capture them. Set private or no-store caching for personalized previews, and separate preview responses from public publishing caches. After changing permissions, test both paths: an authorized editor should still see the preview, while a signed-out request should receive an error or only published data. For a WordPress or Drupal site, review core settings, custom routes, API serializers, preview plugins, and security headers together. A single extension that bypasses normal content permissions can reopen an otherwise well-protected API.
You Might Also Like
- Why Old CMS Paths Keep Appearing in Logs After a Website Migration
- What Is New With CMS Migration and Web Development in August 2026? Latest release notes and search documentation and Key Takeaways
- How to Verify CMS Migration and Web Development Claims in 2026: release notes and search documentation, Evidence, and Red Flags
