WordPress
Nonce
Nonce is a WordPress security token tied to a user, an action, and a time window that proves a request came from a page WordPress itself generated. Despite the name, it can be reused within its window.
How it is measured
WordPress creates one with wp_create_nonce( 'delete-post_55' ), adds it to forms with wp_nonce_field(), and checks it on the server with wp_verify_nonce() or check_admin_referer(). A valid nonce returns 1 for the first half of its life and 2 for the second; false means invalid or expired. The lifetime is 24 hours, split into two 12-hour ticks.
In a failed request you will see the message The link you followed has expired, or a REST response with rest_cookie_invalid_nonce and status 403. The REST nonce travels in an X-WP-Nonce header.
Worked example
A page cache stores a contact page for 48 hours. The form has a hidden _wpnonce generated when the page was cached. After a day, every submission fails with a 403 from the AJAX handler and the owner sees zero leads for two days.
Excluding that form's page from cache, or loading the nonce through a short REST call, restores submissions. The nonce was never wrong; it was stale.
How it differs
A nonce confirms intent and freshness, but a capability answers whether the user is allowed to act. Passing a valid nonce does not mean the user can delete the post, and holding the capability does not defend against a forged link. CSRF is the attack the nonce is designed to block.
Common errors
Treating a nonce as authentication. Checking it and skipping current_user_can. Caching pages with a nonce inside for longer than 12 hours. Using the same action name for every form. Printing a nonce into a public URL where it can leak through referrer headers.
In practice
Read your custom admin-ajax and REST handlers this week. Each should check a nonce and a capability, in that order. If you use a page cache, test logged-in and logged-out forms the day after a cache fill.