development

WordPress Nonce

A WordPress nonce is a one-time security token that verifies a request—such as submitting a form, saving settings, or deleting a post—is intentional and comes from a legitimate source. The name s...

WordPress Nonce

A WordPress nonce is a one-time security token that verifies a request—such as submitting a form, saving settings, or deleting a post—is intentional and comes from a legitimate source. The name stands for “number used once,” though in WordPress the token actually expires on a time window rather than being single-use.

Quick definition: A WordPress nonce is a hashed token appended to URLs and forms that WordPress checks before processing any sensitive action. If the token is missing or invalid, WordPress rejects the request. As of WordPress 6.4, the default nonce lifetime is 24 hours, split into two 12-hour “ticks.”

Why WordPress Uses Nonces

Nonces exist to block Cross-Site Request Forgery (CSRF) attacks—where a malicious site tricks a logged-in user’s browser into sending unauthorized requests to their WordPress dashboard. Without a nonce, an attacker could craft a link that silently deletes posts or changes your admin password the moment a logged-in admin clicks it.

We see this vulnerability exploited on client sites that run outdated plugins—plugins that skip nonce verification are a common vector in WordPress security incident reports.

WordPress’s Security documentation confirms that nonces should be verified on every form submission and AJAX action that changes site data.

Where You’ll Encounter Nonces

You run into nonces in three common situations:

  • Admin forms — every core settings page embeds a nonce field automatically
  • AJAX requests — custom JavaScript that calls admin-ajax.php must pass a nonce in the request header or POST body
  • Plugin and theme actions — any plugin that adds a delete link, bulk action, or save button should include a nonce

When we audit plugin code during client site reviews, missing nonce checks on AJAX handlers are one of the first red flags we look for.

How Nonces Work in Practice

WordPress generates a nonce using wp_create_nonce( 'action-name' ) and verifies it with wp_verify_nonce() or check_admin_referer(). The action name scopes the token—a nonce for delete-post won’t validate a save-settings request.

// Generate a nonce field inside a form
wp_nonce_field( 'save_my_settings', 'my_plugin_nonce' );

// Verify on form submission
if ( ! check_admin_referer( 'save_my_settings', 'my_plugin_nonce' ) ) {
    wp_die( 'Security check failed.' );
}

One detail that catches plugin developers off guard: nonces are user-specific. A nonce generated for one logged-in user won’t validate for a different user, which means cached pages that embed nonces can cause verification failures. The standard fix is to deliver nonces via a separate AJAX call or localize them with wp_localize_script() after excluding nonce-containing pages from full-page caching.

When Nonce Errors Appear

If you’ve ever seen “Are you sure you want to do this?” in your WordPress admin, a nonce check failed. Common causes:

  • Leaving a settings page open for more than 24 hours before saving
  • A caching plugin serving a stale form with an expired nonce
  • A plugin that didn’t implement nonce verification correctly

Refreshing the page generates a fresh nonce and resolves the error in most cases. If the error persists, a caching misconfiguration or plugin conflict is the likely cause.

  • CSRF (Cross-Site Request Forgery) — the attack type nonces prevent
  • Capability checks — used alongside nonces to verify a user has permission to perform an action
  • wp_verify_nonce() — the core function that validates nonce tokens
  • check_ajax_referer() — nonce verification specific to AJAX requests
  • Transient — another time-limited WordPress data mechanism, used for caching rather than security

Additional reading:

Back to Glossary