12 WordPress Admin Mistakes That Leak Private Data

Most WordPress leaks aren’t hacks, they’re settings. A private draft’s images sit at a public URL and the REST API hands out usernames. Here are 12 to fix.

When people picture a WordPress privacy problem, they picture a hacker. The reality is far more boring and far more common: the site is handing out private information because that is what its default settings do. A draft you never published has images anyone can open. An endpoint most owners have never visited lists every username on the site. A debug file quietly logs data where search engines can crawl it. No attacker required, just defaults nobody changed. Here are twelve of those mistakes, and the fix for each.

What To Know

WordPress privacy leaks are usually configuration, not intrusion. Media files stay public at their direct URL even when the post is set to private, the REST API exposes usernames and your full media list to anyone by default, and attachment pages and debug logs can end up indexed by Google. On top of that, over-broad user roles hand member emails and form data to people who should never see them. You close the gaps by protecting your uploads, locking down the REST API and user enumeration, disabling attachment pages, tightening roles, and keeping logs and backups out of your web root.

Why these leaks happen

WordPress is public by default in ways that surprise people. Setting a post to private or draft controls who can read that post, but it does nothing to the files attached to it or to the data your site exposes through its API. The uploads folder has to stay web-accessible for your images to load, so a private post’s media still sits at a guessable URL. And the REST API is designed to answer questions about your content, including who writes it. Understanding that split, the post is protected but the plumbing is not, is what turns these twelve mistakes from invisible into obvious.

12 admin mistakes that leak private data

1. Assuming a private post hides its media. Uploaded files stay public at their direct /wp-content/uploads/ URL no matter the post’s status. Do not attach sensitive PDFs or images to a private post and assume they are hidden; use a file-protection plugin or server rules for anything truly private.
2. Leaving the REST users endpoint open. Visiting /wp-json/wp/v2/users returns your usernames, display names, and author URLs to anyone, logged in or not. Restrict or disable the endpoint and block user enumeration.
3. Display names that equal login usernames. If your author name is also your login, you have handed out half of your credentials. Set a display name that differs from the username on every account.
4. Directory listing enabled on uploads. On some servers, opening a folder URL under /uploads/ lists every file in it. Disable automatic directory indexing so nobody can browse your media library by hand.
5. Attachment pages left on and indexed. WordPress can generate a separate page for each media file, and search engines index them, exposing files you never linked. Disable attachment pages or redirect them to the parent post.
6. A debug log sitting in the open. Turning on debug logging writes a debug.log in your content folder that can contain file paths, queries, and data, and it is often crawlable. Keep debug off in production or move and block the log file.
7. Backups and database dumps in the web root. A .sql dump or backup zip left in a public folder is a one-click download of your entire site and its user data. Store backups off the server, never inside a web-accessible directory.
8. Over-permissioned user roles. Handing Editor or Admin to a contractor or virtual assistant exposes every draft, member record, and setting. Grant the least role that does the job, and audit who has access.
9. Form entries visible to too many people. Contact and signup plugins often store names, emails, and messages in your database, viewable by more roles than you realize. Limit who can see entries, prune old ones, and avoid storing what you do not need.
10. Member and commenter emails left exposed. Comment author emails, CSV exports, and unprotected member directories all leak addresses. Restrict exports, hide member lists, and be careful what comment data you display.
11. Forgetting to discourage indexing on staging. A staging or dev copy without the search-engine setting enabled gets crawled, indexing private or duplicate content. Turn on the discourage-search-engines option and password-protect non-production sites.
12. Sharing preview and draft links carelessly. A preview URL lets anyone who has it read an unpublished post. Treat those links as sensitive, and do not paste them into public tickets, chats, or documents.

A 10-minute privacy sweep

You can catch most of these in one sitting. Open a private browser window and try loading an image URL from a private post, then visit your /wp-json/wp/v2/users endpoint to see what it reveals. Search Google for site:yourdomain.com and look for media or attachment pages you did not expect. Open a couple of /uploads/ folder URLs to check for directory listing. Finally, review your user list and roles, and confirm no debug log or backup is sitting in a public folder. Ten minutes here saves a very bad afternoon later.

Frequently Asked Questions

Are my private post’s images really public?

Yes, by default. Post visibility controls the post, not the files. An image attached to a private or draft post remains downloadable at its direct upload URL unless you add file-level protection.

What does the WordPress REST API expose?

By default it can return your usernames, display names, author URLs, and full media list to anyone. That is useful for developers but a privacy risk, so restrict the endpoints you do not need public.

How do people find my hidden files?

Usually by guessing the predictable /uploads/YYYY/MM/ path, through indexed attachment pages, or via the REST API’s media list. None of that requires hacking, just knowing where WordPress puts things.

Do I need a plugin to protect uploads?

For genuinely sensitive files, yes or a server-level rule. WordPress keeps uploads public so images load, so protecting them means routing access through a handler or blocking direct requests with server configuration.

What’s the fastest thing to fix first?

Lock down user enumeration and tighten roles. Those two stop the most common reconnaissance and limit who can reach private drafts and member data, which covers a large share of accidental leaks.

Is this different from getting hacked?

Yes. These are accidental exposures from settings and defaults, not break-ins. Fixing them also makes a real attack harder, since attackers usually start by harvesting exactly this kind of leaked information.

Final Takeaway

The uncomfortable truth is that most WordPress privacy incidents are self-inflicted, built from defaults left in place rather than doors kicked in. Walk the list once: protect your uploads, close down the REST API and user enumeration, kill attachment pages, keep logs and backups out of the web root, and give people the smallest role they need. For deeper reference, WordPress’s own hardening guide is worth a read. Do the ten-minute sweep, fix what you find, and you turn a site that quietly overshares into one that keeps private things private. For more upkeep, see how to fix a WordPress updating error and how to vet a plugin before installing it.