WordPress action denied despite being logged in: check permissions and blocks

Understand an action denied after login

You open the dashboard, but WordPress refuses to edit a page, save a setting, or access a section. The message may report insufficient permission or display a 403 error. Being logged in proves your identity in a particular context; it does not automatically authorize every operation.

The desired result is an authorized action that works with the right account on the right site, without opening unnecessary access. A refusal may also be normal: an author does not have the same responsibilities as an administrator. The goal is therefore not to remove every protection encountered.

This guide covers self-hosted WordPress, WordPress.com, and multisite networks. Identify your environment before applying a correction. If login itself continually returns to the form, start with session troubleshooting instead. Here, we investigate why one specific operation fails while the dashboard remains accessible.

If you instead want to reduce access that has become excessive, use the deliberate permission-reduction path. It retains the account and its content, then checks the actions that should continue working and those that should be denied. The same refusal can therefore represent either a fault or the expected outcome of a management decision.

Preserve your work and record the exact refusal

Copy unsaved text to a private location before reloading the editor or logging out. Then record the action, time with time zone, domain, and exact refusal text. Distinguish a missing menu, a page that does not open, and a rejected save: these observations lead to different checks.

Record the WordPress and affected component versions from accessible screens or with the responsible person’s help. Do not assume that a procedure for another version has exactly the same buttons. Also state whether the issue began after an update or permission change.

A reader, author, and administrator do not have the same diagnostic access. If your account cannot view users, ask the responsible person to check. Do not borrow their password: they can inspect your assignment or perform an authorized check themselves.

Choose between three paths without a new plugin

The first path checks identity, site, and capabilities. Start here if only one account fails, a section is missing, or you have just received an invitation. It also helps recognize an expected restriction rather than investigating a fault that does not exist.

The second path examines an old form and component permissions. Choose it when refusal happens only on saving, after a long writing session, or within a store, form, or particular content type.

The third looks for a server or firewall block. It becomes relevant when the response is branded by a protection service or a security event matches the test. A 403 error alone is not enough to choose this path: the same status can come from several layers.

Approach 1: confirm the account and site actually being used

1. In the dashboard, open your profile from your name in the top bar. Verify the account username; the publicly displayed name may differ. Also compare the domain with the site you are managing. A staging copy and public site may display the same title while having different users.
2. If you have several identities, preserve your work first, then log in again with the explicitly invited account. A separate browser profile lets you compare without immediately closing other sessions. Never copy cookies from one profile to another to fabricate access.
3. Return to the operation through its normal menu rather than an old bookmark containing a content ID. If that resolves the refusal, confirm the result on a harmless draft. If the right account remains blocked in the right place, continue with permissions rather than repeatedly logging in again.

Check capabilities, not just the role name

A role groups capabilities: permissions for specific actions. By default, an author can manage their own posts, while an editor can also manage other people’s posts. The Contributor role does not include publishing or uploading media. These rules explain some legitimate refusals.

An authorized administrator can open Users, then All Users, open the affected user, and record their role; depending on the interface language, the menu may be called Comptes. Start by reading, without a bulk change. Compare the actual assigned task with the requested operation, not with a company job title.

A permission can depend on the target content, its author, and whether it is published or a draft. Being able to edit your own post does not prove you can edit a colleague’s. Ask the responsible person to compare two precise cases before declaring the account’s permissions faulty.

If an insufficient assignment is confirmed, the responsible person records the current role, opens the account, and selects only the role approved for the task. After saving, they check the needed action and one action that must remain forbidden. If this correction does not help, they restore the documented assignment. They do not promote every author or change the default role for new registrations.

Prepare a deliberate reduction in permissions

A contributor may have received an elevated role during a migration or troubleshooting and no longer need it. The authorized manager starts by describing the current task without deleting the account or reassigning posts. Confirm the identifier, domain, and affected content. Keep independent, working administrator access: do not experiment on your only management account. On multisite, have it confirmed before this change whether the account is a super administrator. If so, this local path is insufficient: have the network manager handle the decision.

Record the current role, any additional roles, and the component managing them. Plan a targeted return to that documented assignment if a legitimate function becomes unavailable. Changing custom roles requires a backup and tests on a copy; a general production restore should not be used to undo a simple role choice.

Choose two test cases before the change. In an illustrative example, the person must continue writing and publishing their own posts but must no longer manage plugins. The native Author role may suit that task on a standard site; it remains too powerful if someone else must approve publication. Store roles and capabilities added by a component require their own comparison.

Reduce the role from the correct user’s profile

Using the retained management access, open Users, All Users, then Edit for the identified user. The menu may be translated as Comptes. Record the current assignment in the profile, select the chosen value under Role, then save with Update User. Handle a single user for this first change. Do not change the default registration role. Access to a profile does not always permit changing its role: the manager must have user-management and role-changing permissions for that account. On multisite, have the network administrator confirm the scope.

Reopen the profile to verify the value was retained. Posts do not change authors merely because of this choice: still check a sample piece of content and its byline. Do not delete the account to reduce access; deletion also affects other data and raises a separate question about what happens to its content.

Have the affected person reopen the dashboard in an appropriate session after preserving their work. If the proposed role is unavailable or a plugin restores the old value, stop successive changes and identify that manager. A synchronization system may be the actual source of the assignment. If the action fails despite your own permissions, return to the guide’s account, nonce, or protection diagnosis rather than borrowing a more powerful identity.

Inspect remaining capabilities before drawing a conclusion

A displayed Author role does not, by itself, demonstrate that all administrative privileges are gone. Capabilities may be assigned directly to a user, added by a plugin, or decided at the time of the check. The native role-change mechanism removes old roles; it is not a reset of every authorization path.

The maintainer can read the profile and capabilities with WP-CLI, already installed and authorized. Replace the path, URL, and 123 with the confirmed context. Run the first command first and confirm identity. The second then displays the site ID, roles, direct assignments, and network super-administrator status. The second example uses WordPress functions to read the account in the current site’s context. It retains true and false values and role names without assuming a wp_ table prefix. This optional read is for the maintainer; no PHP file should be uploaded to the site.

In attributions_directes, role names are assignments, not expanded lists of their permissions. A capability set to true is directly granted; false expresses a stored denial. An empty list does not prove the absence of inherited or dynamic permissions. This read does not certify decisions by filters and business components: always compare a functional test. Do not delete unknown capabilities. If super_admin_reseau is true, stop this local variant here before the role-change command. Keep output private and leave plugins loaded to observe the site’s normal context.

wp --path='/chemin/wordpress' --url='https://votre-site.example/' user get 123 --fields=ID,user_login,roles --format=json
wp --path='/chemin/wordpress' --url='https://votre-site.example/' eval '$u = get_user_by("id", 123); if (!$u) { WP_CLI::error("Compte introuvable"); } $u->for_site(get_current_blog_id()); WP_CLI::line(wp_json_encode(array("site_id" => get_current_blog_id(), "roles" => $u->roles, "attributions_directes" => $u->caps, "super_admin_reseau" => is_multisite() && is_super_admin($u->ID)), JSON_PRETTY_PRINT));'

WP-CLI variant for a simple, documented assignment

For a standard account whose inventory confirms a single role, a maintainer can make the change with the command below. It uses the example of a task requiring publication of the user’s own posts; author is not a universal choice. Replace the environment values and identifier, then have the role confirmed before execution.

Run it only if the preceding identity, URL, and inventory match the approved change. On multisite, --url selects the subsite; a wrong target can assign a role on another network site.

The set-role command replaces previous roles. Do not use it as a simple addition on an account with multiple roles: legitimate functions could disappear. It also does not address all the direct capabilities mentioned earlier. If customization is involved, use its documented mechanism and rollback plan rather than forcibly converting to a native role.

After the output, reread the profile and repeat functional checks. If the command fails, do not rerun it across a list of accounts or skip loading plugins to manufacture success. A role manager must be examined in its normal context. No new plugin is needed for this native change.

wp --path='/chemin/wordpress' --url='https://votre-site.example/' user set-role 123 author

Check retained functions and expected refusals

With the target account, open a control draft without sensitive data and verify the operations actually needed. Also check the action that should now be denied, using its normal entry point or the scenario prepared by the maintainer. A disappeared menu does not prove that the server denies the operation; a visible menu does not prove it accepts it either. Do not attempt a real installation, deletion, or payment for this test. For the Author example, verify saving a draft owned by that account and denial of access to the plugin-management screen identified in advance by the responsible person. That latter check verifies this screen; it does not alone prove denial of every API route in the component.

Check an integration using the same user if it is part of the task. Its permissions may depend on the account’s capabilities. However, reducing a role does not revoke its application secret, sessions, or hosting access. Decide separately which access should remain valid.

If a legitimate function has disappeared, compare it with the task and required capabilities. Restore only the previously approved assignment when the rollback plan calls for it, then correct the choice on a copy. If an excessive privilege persists, have its source investigated rather than declaring the reduction complete. On multisite, check the subsite role and super-administration separately: local demotion does not remove network status. If the account is a super administrator, stop this local path and have the decision handled at network level; do not declare the privilege removed after only changing a role. Record the old state, new state, test cases, and verification limits.

On multisite, distinguish a network user from a site member

A multisite network combines several sites in one installation. A user may exist in the network without having the expected role on the selected site. Under My Sites, check which site is actually open. The network administrator can verify membership and role on that specific site.

The super administrator manages the network; a site administrator does not possess all those powers. Installing new plugins or themes normally falls under network administration. A refusal for these operations therefore does not imply a corrupted local account.

If membership is missing, ask for a correction limited to the affected site. Do not request super-administrator status to publish a post. After the intervention, check the action on this site and the absence of unjustified expansion to others. Every network change must be prepared by its manager with a backup and clearly identified scope.

On WordPress.com, check invitation and ownership

A logged-in WordPress.com account does not necessarily have access to every site. Have the invited address and invitation status confirmed in the site’s user list. Accept the invitation with the intended identity, then select the site. A sent invitation does not prove it has been accepted.

Do not confuse subscribing to updates with editorial permission. Check the assigned role in the site dashboard. Interface layouts may vary; follow the user-management section rather than a memorized path for another layout.

Even as administrator, you do not necessarily own the site, subscription, or domain. Some ownership or purchase operations belong to the relevant holder. Promoting a role does not replace that ownership. If a function depends on the plan or managed hosting, have WordPress.com confirm access without trying to change unavailable files.

Approach 2: reopen an outdated form cleanly

If an old tab refuses to save while navigation still works, compare it with a fresh screen.

WordPress uses protective tokens called nonces, among other measures. They have a validity period and may become invalid after a session change. A form that is still visible is therefore not necessarily usable. However, this token grants no capability: refreshing the screen does not repair a missing permission.

If the fresh test succeeds, recover your text without blindly reusing the old form. If the refusal returns immediately, keep the message and move to component or network-response diagnosis. Do not disable token checks to make the request acceptable.

1. Preserve unsaved content in a private note, then open a fresh screen for the same function.
2. Log in again if the session requests it and try a simple draft without publication or notification.
3. Reopen the draft to verify that the change was actually retained.

Identify the denied request without exposing its secrets

For a more precise diagnosis, open browser developer tools, then Network, before a controlled test. Select the request corresponding to the action and record its status and response message. Do not manually resend a payment, deletion, or message to a customer.

The REST API is a channel WordPress uses to exchange data. With dashboard cookie authentication, it also checks a nonce. The code rest_cookie_invalid_nonce indicates an invalid-token check; it does not automatically mean your role was removed.

A request may also be treated as unauthenticated if the expected token is missing, despite a visible dashboard. Send the error code to the maintainer without copying cookies, token values, or authorization headers. If the response is an HTML blocking page rather than a WordPress message, the third path becomes relevant.

Examine permissions specific to the affected component

If failure affects only one section, identify the plugin, theme, or custom development providing it. A custom post type may have its own capabilities. The maintainer needs to check the action on the affected object, not merely whether the account has the Administrator label.

A hidden menu entry alone does not prove a permission is missing. Conversely, seeing a button does not guarantee server-side authorization for the action. Report that difference to the component’s publisher; do not try to bypass a restriction by inventing an administrative address.

For WooCommerce, the Customer and Shop Manager roles come from WooCommerce, not WordPress core. The latter allows store management without every administrative permission, but its permissions still need comparison with the precise task. Do not assign these roles on a site without a store to resolve a general refusal.

Isolate a recent change without interrupting production

If the issue follows a component change, prepare a test copy with its own database and the affected versions. Before reproducing the action, disable payments, emails, notifications, and other external effects. A copy that sends real orders is not a safe environment.

On that copy, the maintainer can restore the known setting or normally isolate the suspected component, then repeat the same test. Preserve the initial state and restore each element before testing the next. If the refusal disappears, that guides analysis without proving all the component’s protections are unnecessary.

In production, require a restorable backup and rollback before changing custom permissions. Do not reset all roles or edit serialized data directly in the database. If the component remains essential and the cause is unknown, send a reproducible case to its support.

Approach 3: distinguish a WordPress refusal from a server block

A web application firewall, often abbreviated WAF, inspects requests sent to the site. It can block a legitimate request before WordPress processes it. A security page, request ID, or refusal tied to specific content justifies searching its events.

Status 403 means the request is denied; it does not by itself identify the responsible component. Hosting protection, a server rule, or WordPress can produce it. The page’s appearance provides a clue, not enough proof to disable a service.

If Cloudflare is involved, record the Ray ID when available, the time, and request path. This ID helps locate the event but is not a diagnosis or proof of blocking on its own. Nor should you conclude that a page without a logo rules out Cloudflare involvement.

Have the exact rule and a limited correction checked

The protection manager or host correlates the refusal with security events. If the site uses Cloudflare, proceed as follows with authorized access:

If a false positive is confirmed, ask for an adjustment proportionate to the necessary rule and path. Keep the previous configuration and plan how to remove the exception. An allowance covering the whole dashboard or all visitors is not the first choice for one particular form.

After the correction, repeat the authorized action, then check that anonymous access is still denied where required. If the test fails, have logs reexamined rather than accumulating exceptions. Do not globally disable the WAF, two-factor authentication, or login protections to finish a post.

1. Open Security Events in the old navigation, or Analytics and then the Events tab in the new security dashboard.
2. Search for the test time and available Ray ID; also compare the domain, path, and request method.
3. Record the rule and action actually applied before requesting a correction. Some results are sampled: absence from the display is not enough to clear the firewall of involvement.

Prepare a usable support request

If the issue persists, send the case to the right contact: the user manager for assignments, publisher for a specific function, network administrator for multisite, or host for the server. On WordPress.com, specify the affected site and account so access can be checked within the service.

Describe the intended action, exact refusal, time, versions, and tests performed. State whether your own draft works, another author’s fails, and a fresh screen changes the result. Attach only a sanitized screenshot or necessary request characteristics.

Do not publicly send passwords, cookies, configuration files, or a complete network export. Such exports may contain private content and session secrets. Use the provider’s secure channel and have the actually required data specified before transmitting anything sensitive.

Confirm the repair without retaining excessive privileges

With the account normally intended for the task, repeat the operation on suitable test content. Then reopen the resource to confirm it was saved. Do not validate only the appearance of a button: the useful result must exist without duplication or unexpected external effect.

Also check an action that must remain forbidden to this account. This negative check avoids treating a general opening of permissions as a repair. Have temporary permissions removed, necessary components restored, and diagnostic exceptions closed when no longer needed.

Finally, keep the accepted cause, old setting, correction, and checks performed. At the next update, this record lets you compare facts rather than install a new plugin at the first refusal. The right outcome remains access proportionate to the task, on the intended site, with the usual protections in place.

Compare a capability on a specific object without granting permission

The maintainer can check an effective permission without changing roles. On a copy, with WP-CLI already available, the example below asks: can account 123 edit post 456 on this site? Replace both identifiers, the path, and the URL with confirmed values. --user selects the account whose capabilities are evaluated; permission to use SSH remains separate access.

The command changes neither the post nor permissions. Compare a draft owned by the account with content by another author, keeping plugins loaded. A difference may be normal according to role and content status. For a custom type, the component may define its own capabilities.

An allowed result does not validate the nonce, REST request, or firewall in the browser path: those are separate checks. Conversely, a refusal does not justify promotion to administrator. It supplies a precise question for the permissions manager. No additional roles plugin is needed for this read.

wp --path='/chemin/wordpress' --url='https://votre-site.example/' --user=123 eval 'echo current_user_can("edit_post", 456) ? "Autorisation accordee
" : "Autorisation refusee
";'