As WPGraphQL continues to power more decoupled WordPress applications — from startups to enterprise-scale projects — access control is becoming a more common topic of concern. One area that often prompts discussion is whether exposing users via the GraphQL API poses a security risk.

In this post, we’ll look at how WPGraphQL handles user visibility by default, why that behavior aligns with WordPress core, and how you can restrict access if your use case requires stricter control.

Public Authors in WordPress

WordPress core treats users that are authors of published content as public entities. Their names and profile links are exposed in various ways across a default WordPress site, including:

Author archive pages (e.g. /author/jdoe)
Post bylines with author links
Public REST API endpoints (e.g. /wp-json/wp/v2/users)
XML sitemaps (e.g. author-sitemap.xml)

This public exposure allows users to be attributed to the content they create. WPGraphQL follows this same model – users with published content are considered public and are queryable with WPGraphQL by default.

This approach is consistent with the underlying philosophy of WordPress, where content creators are visible unless there’s a reason to hide them.

When Public Access Isn’t Desirable

In some environments — particularly where WordPress is used as a headless CMS — exposing user data, even limited to names and slugs, may not be ideal.

Common reasons include:

Preventing user enumeration as part of security hardening
Compliance requirements that mandate stricter access to user data
Sites that don’t publicly associate content with authors at all

Even though WPGraphQL does not expose sensitive fields like usernames or email addresses by default, developers building secure, API-driven applications may still prefer to hide user data entirely from unauthenticated requests.

How to Restrict User Access in WPGraphQL

WPGraphQL includes filters that allow you to control who can access user data and under what conditions. Below are two common approaches.

Option 1: Hide All Users from Unauthenticated Requests

You can use the graphql_object_visibility filter to restrict access to all users unless the request is authenticated:

add_filter( 'graphql_object_visibility', function( $visibility, $model_name, $data, $owner, $current_user ) {

	// If the current wpgraphql request is not authenticated, and the model is a UserObject, make users private
	if ( ( ! isset( $current_user->ID ) || 0 === $current_user->ID ) && 'UserObject' === $model_name ) {
		$visibility = 'private';
	}

	return $visibility;

}, 10, 5 );

This ensures that no users will be returned from the GraphQL API unless the request is made by a logged-in user.

Option 2: Customize Visibility Rules Per User

If your use case requires more nuance — for example, only allowing users to be queried by authenticated users with a specific capability, or some other criteria you choose:

add_filter( 'graphql_object_visibility', function( $visibility, $model_name, $data, $owner, $current_user ) {

	// Ensure users are private unless the request is from a user with specific capabilities
	if ( ! current_user_can( 'do_something_specific' ) {
           return 'private';
        }

	return $visibility;

}, 10, 5 );

This can be extended to allow users to access only their own account, or to enforce custom logic based on metadata, capabilities, or authentication tokens (such as JWT claims). Whatever criteria you have for your specific application can be applied to meet your needs.

Tradeoffs to Consider

While restricting user access may be the right call for some decoupled applications, it’s important to consider the tradeoffs — especially if your site relies on author-related features.

Making all users private can interfere with:

Author archive pages (/author/slug)
Byline components that need display names or author slugs
Filters or dropdowns that allow visitors to browse by author
SEO plugins that include author pages in sitemaps

If your frontend or theme relies on any of these features, hiding users may break expected functionality. In some cases, it may be better to restrict specific fields (e.g. hiding email or username – something WPGraphQL does out of the box for non-authenticated requests) while still allowing name or slug to be visible.

Summary

WPGraphQL follows the same public access model that WordPress core uses — exposing users who have published content. This is consistent with how authors appear across WordPress sites in archives, bylines, sitemaps, and REST API endpoints.

That said, WPGraphQL gives you full control to restrict access to user data when needed. Whether you want to block access entirely, limit it by role, or apply fine-grained rules, you can do so using built-in filters.

If you’re building a public-facing site that relies on author pages, be sure to evaluate the tradeoffs before locking things down too tightly.

For those looking to expose more users — including users without published content — check out the following resources:

Whether you need to tighten access or open things up, WPGraphQL offers the flexibility to adapt to your project’s needs.