"Are you sure you want to do this?" — fixing the WordPress nonce/security check error
TL;DR: This message is WordPress's nonce (a one-time security token embedded in forms and links to prevent certain attacks) failing verification, almost always because the token expired from sitting open too long, was served from a cached page so it no longer matches your current session, or a plugin conflict interfered with how it was generated or checked, not because your account actually lacks permission to do the action.
What a nonce actually is and why WordPress uses one
A nonce ("number used once") is a short-lived, unique token WordPress embeds into forms, action links, and AJAX requests specifically to verify that a submitted request genuinely originated from a page WordPress itself generated recently for that specific logged-in user, rather than from a forged or replayed request (the security concern this protects against is called cross-site request forgery, or CSRF). When you submit a form or click an action link, WordPress checks the accompanying nonce against what it expects; if they do not match, or the nonce has expired, WordPress refuses the action and shows this message rather than proceeding, since it cannot confirm the request is legitimate.
This is a deliberate security feature working as intended in the vast majority of cases where it appears; the message is disruptive but usually reflects a timing or caching issue rather than an actual security problem or a bug in WordPress itself.
Cause 1: the page or session simply expired
Nonces have a limited lifetime, by default around 24 hours in WordPress core, but this can feel much shorter in practice because the relevant expiry is often tied to how long a specific page has been open in your browser rather than your overall login session length. If you open an edit screen, get distracted, and come back to submit the form significantly later, the nonce embedded in that page when it loaded may no longer be considered current, even though you are still logged in and your session itself has not expired.
This is the most common and most benign version of this error, and the fix is simply refreshing the page (which generates a fresh nonce) before retrying the action, accepting that any unsaved changes on that page may need to be re-entered since a refresh discards them.
Cause 2: a cached page serving a stale nonce
If your site runs a caching plugin or sits behind a CDN with full-page caching, and a page containing a nonce-protected form gets cached and served to multiple visitors or across multiple sessions, every visitor receives the exact same nonce value embedded in that cached HTML. Since a nonce is meant to be tied to a specific user's session, a cached, shared nonce frequently fails verification, because the server-side session context does not match what a shared cached token implies.
This specifically affects admin-area actions, logged-in-user-specific forms (like a frontend comment form with additional fields, or a membership site's account page), and any page containing a nonce that should not have been cached in the first place. Properly configured caching should exclude logged-in user sessions and any page containing user-specific nonces from full-page caching; if this error correlates specifically with actions on pages you know are cached, the caching configuration itself is the underlying cause to fix, not just this specific symptom.
Cause 3: a plugin conflict
Some plugins, particularly security plugins, other caching-adjacent plugins, or anything that modifies how sessions or cookies are handled, can interfere with nonce generation or verification, either by altering session behavior in a way that breaks the expected user-context matching, or through a direct compatibility conflict between two plugins both trying to hook into the same WordPress security functions.
If this error appears consistently on a specific action (not just as an occasional expired-page issue) and correlates with a recently installed or updated plugin, particularly a security or caching plugin, temporarily deactivating it and retesting isolates whether it is the cause.
Cause 4: multiple tabs or browser sessions
Having the same admin page open in multiple browser tabs, or being logged into the same WordPress account from multiple browser sessions simultaneously, can occasionally produce nonce mismatches if an action in one tab invalidates or regenerates session-related state that another open tab's nonce was relying on. This is a less common cause but worth ruling out if the error appears specifically when working across multiple open admin tabs at once.
A diagnostic table
| Pattern | Likely cause | Fix |
|---|---|---|
| Happens after leaving a page open a long time | Expired nonce, normal | Refresh the page, retry |
| Happens consistently, right after page load | Cached page serving stale nonce | Exclude the page/area from caching |
| Happens on one specific action after a plugin update | Plugin conflict | Deactivate the plugin, retest |
| Happens when working in multiple tabs of the same admin page | Multi-tab session conflict | Work in a single tab, refresh before submitting |
| Happens for all logged-in users uniformly on a specific page | Full-page caching misconfiguration | Add that page/URL pattern to cache exclusions |
The fix in each case
For the ordinary expired-nonce case, simply refreshing before retrying resolves it every time and requires no configuration change; this is the expected behavior of a working security feature, not a bug to permanently fix. For caching-related cases, configure your caching plugin or CDN to exclude wp-admin entirely (which should already be a caching default, but is worth confirming explicitly) and to exclude any frontend pages containing logged-in-user-specific forms or nonce-protected actions, rather than caching them alongside your general public pages. For plugin conflicts, after confirming which plugin is responsible through deactivation testing, check for an available update (many such conflicts get resolved in subsequent releases as compatibility issues are identified and patched) or contact the plugin's support with the specific conflict details. For multi-tab issues, working in a single tab for a given admin task, and refreshing before submitting if you have had multiple tabs open, avoids the conflict.
FAQs
Does this error mean my account has been compromised?
No, this specifically indicates a failed security token check, not a permissions or account compromise issue; your account access itself is unaffected, and the message is WordPress correctly refusing to process a request it could not verify as current and legitimate, which is the security feature functioning as intended even when the underlying cause is benign (like an expired page).
Will refreshing the page lose my unsaved changes?
Yes, typically, since a fresh page load generates a new nonce but also reloads the form to its last-saved state, discarding anything typed since that load. If you have substantial unsaved content, copying it elsewhere before refreshing (into a separate text document, for example) preserves it before you retry the action on a fresh page load.
Why does this happen more often on my site than others I've used?
If it happens frequently rather than occasionally after genuinely long idle periods, this points toward Cause 2 or Cause 3, a caching or plugin-related issue specific to your site's configuration, rather than the normal, occasional expected behavior of nonce expiry that any WordPress site experiences from time to time.
Can I extend how long a nonce stays valid?
This is technically possible through custom code filtering the nonce lifetime, but it reduces the security benefit the short lifetime is designed to provide, and is rarely the right fix compared to addressing the actual underlying cause (caching misconfiguration, a plugin conflict) if the error is happening more often than normal expected page-idle timeouts would explain.
Does logging out and back in fix this?
It can, since it forces a completely fresh session and a fresh page load with a current nonce, but it is a broader reset than usually necessary; simply refreshing the specific page you are working on is typically sufficient and less disruptive than a full logout and login cycle.
Is this related to the "cookies are blocked" error I sometimes see instead?
They are related but distinct; nonces rely on session state that is itself often tracked via cookies, so a browser blocking or clearing cookies mid-session can also produce nonce-related failures, but the two error messages point at slightly different root checks WordPress performs, and a "cookies blocked" message specifically indicates the cookie check failed rather than the nonce token itself being invalid.
Should I be worried about this appearing on a form on my site that visitors, not just admins, use?
Not inherently, since nonces protect various forms, not just admin actions, and a visitor occasionally hitting this on a frontend form (a comment form, a frontend submission form) after leaving a page open a long time is the same benign expiry behavior; if it happens very frequently for visitors specifically, checking whether that particular frontend page is being cached inappropriately (Cause 2) is the more likely explanation than anything requiring visitor-side action.
Conclusion
The nonce verification error is a security feature doing its job, refusing to process a request it cannot confirm is current and legitimate, and in the overwhelming majority of cases the fix is as simple as refreshing the page and retrying. It becomes worth deeper investigation only when it happens far more often than occasional page-idle expiry would explain, at which point caching configuration and plugin conflicts are the two causes to check first.
Refresh-and-retry for the occasional case; check caching exclusions and recent plugin changes if it is happening persistently and interfering with normal site use.
HostCloud's managed WordPress hosting configures caching exclusions for wp-admin and logged-in sessions by default, so cached-nonce failures should not originate from our infrastructure layer. Plans start at ₹99 a month at https://hostcloud.in.