post_password, post_password_required(),\nget_the_password_form(), the wp-login.php?action=postpass handler,\nwp-postpass_ cookie semantics, REST password requests, cache isolation,\nprotected comments/feeds, and guarding custom meta, blocks, media, and API\noutput. Use when extending the password form, changing cookie lifetime or\nprotected titles, adding editor/role bypasses, building a headless reader,\nor reviewing leaks where content visibility relies on a post password. Do\nnot use for user login, Application Password, membership, private-file auth,\nor an internal data store that merely reuses the post_password column.\nlicense: GPLv2-or-later\nmetadata:\nwp-skills-author: \"Soczó Kristóf\"\nwp-skills-contact: \"mailto:lonsdale201@hotmail.com\"\nwp-skills-plugin: \"wordpress\"\nwp-skills-plugin-version-tested: \"7.1\"\nwp-skills-wp-version-tested: \"7.1\"\nwp-skills-php-min: \"7.4\"\nwp-skills-last-updated: \"2026-08-22\"Implement or review WordPress's built-in shared-password gate without treating\nit as user authentication or encrypted storage. Preserve the core form/cookie\ncontract, guard every custom output surface, and prevent caches from publishing\nan unlocked representation.
\nRead references/runtime-and-extension-contracts.md\nwhen working on headless/REST access, replacing the form, changing bypass\npolicy, or auditing exactly which core surfaces are and are not protected.
\npost_password or has_password to control public post, page,\nproduct, course, or custom-post-type visibility.post_password_required(), get_the_password_form(),\nget_the_content(), or filters the_password_form.Do not trigger merely for user-password/login code or because an internal data\nstore reuses the column, such as legacy Action Scheduler claim IDs or legacy\nWooCommerce order keys. Verify the field's semantic purpose before auditing it.
\nUse the built-in post password only when all intended readers may share one\nsecret and disclosure of the post title/permalink is acceptable.
\n| Requirement | \nAppropriate mechanism | \n
|---|---|
| One shared secret gates ordinary post content | \nCore post password can fit. | \n
| Per-user grant/revocation, audit, expiry, ownership, subscription, or role | \nAuthenticated users plus capability/entitlement policy. | \n
| Hide the post's existence from anonymous visitors | \nPrivate/custom status plus authorization, not only post_password. | \n
| Protect original media URLs or downloadable files | \nAuthorized delivery outside public uploads or signed/controlled downloads. | \n
| High-value confidential data | \nPurpose-built authentication and authorization; do not rely on a shared post password. | \n
The password is stored as plaintext in wp_posts.post_password; the post body\nis not encrypted. The browser cookie stores a salted PHPass hash, but acts as a\nsite-scoped proof for whichever post has the matching plaintext password. Core\nhas no per-reader identity, revocation list, attempt counter, or audit trail.
post_password value.get_the_password_form() rather than the body.post_password and redirect_to to\nwp-login.php?action=postpass.wp-postpass_ plus COOKIEHASH cookie for the site and\nredirects safely to the post.post_password_required( $post ) verifies that cookie hash against the\npost's current plaintext password.The cookie is not keyed by post ID. Posts sharing a password unlock together;\nentering a different password replaces the cookie, so only one distinct post\npassword works in that browser at a time. Logged-in users do not automatically\nbypass the frontend check.
\nCheck the exact owning post before reading or rendering custom data:
\n$post = get_post( $post_id );\n\nif ( ! $post ) {\n return '';\n}\n\nif ( post_password_required( $post ) ) {\n // Let the owning post template render the core form once.\n return '';\n}\n\nreturn esc_html( (string) get_post_meta( $post->ID, '_acme_summary', true ) );\nUse the same boundary for custom fields, blocks, shortcodes, related records,\ndownloads, JSON, email, exports, and secondary queries. Never infer access from\ncookie presence alone; post_password_required() validates it.
Do not assume these operations enforce the gate:
\nget_post(), get_post_field(), direct post content properties, and $wpdb;get_post_meta() or custom-table lookups;the_content to a raw content string;get_the_post_thumbnail(), attachment metadata, or a public uploads URL;Core template functions protect the ordinary content/excerpt path and several\ncomment, feed, block-binding, and block surfaces. That is not a general data-\naccess policy for plugin code.
\nPrefer styling or a surgical WP_HTML_Tag_Processor change over rebuilding the\nentire form. This retains the action, redirect, unique label/input ID, error\nannouncement, translations, and WordPress 7.1 block-theme button classes:
add_filter(\n 'the_password_form',\n static function ( string $html, WP_Post $post, string $invalid_password ): string {\n $processor = new WP_HTML_Tag_Processor( $html );\n\n while ( $processor->next_tag( 'input' ) ) {\n if ( 'post_password' === $processor->get_attribute( 'name' ) ) {\n $processor->add_class( 'acme-post-password' );\n break;\n }\n }\n\n return $processor->get_updated_html();\n },\n 10,\n 3\n);\nIf full replacement is unavoidable, preserve every contract listed in the\nreference and test classic plus block themes. Filter output is a trusted\nplugin/theme surface: escape translated text and attributes deliberately.
\nWordPress 7.1 wraps the submit control with .wp-block-button and applies\n.wp-block-button__link plus the current button element class for block themes;\nit also enqueues the registered wp-block-button style. A legacy full-form\nreplacement silently loses that improvement.
Scope post_password_required narrowly. For an editorial frontend preview, an\nobject-level edit capability is a defensible bypass:
add_filter(\n 'post_password_required',\n static function ( bool $required, WP_Post $post ): bool {\n if ( $required && current_user_can( 'edit_post', $post->ID ) ) {\n return false;\n }\n\n return $required;\n },\n 10,\n 2\n);\nDo not substitute read_post as a membership check: for an ordinarily\npublished post it is commonly true for logged-in readers and does not express\nthe intended entitlement. Prefer a dedicated capability or an explicit\nobject-level entitlement service. Remember that this filter influences every\ncaller, including comments, blocks, feeds, and REST preparation.
Prefer the core posts endpoint for core post fields. A single-item request may\nsupply the plaintext password; without it, content.rendered and\nexcerpt.rendered are empty and their protected flags are true. A wrong\nsupplied password returns rest_post_incorrect_password with HTTP 403. An\nauthenticated editor using context=edit can access content when allowed to\nedit that post.
Passwords in query strings can enter browser history, proxy/CDN logs,\nanalytics, traces, and error reports. Require HTTPS, redact the parameter, do\nnot persist it in client state, and never shared-cache a successful response.\nFor higher-value or per-user content, use authenticated authorization rather\nthan extending the query-password design.
\nCustom endpoints must independently protect every additional field. A public\npermission_callback followed by an unchecked meta/custom-table read bypasses\nthe post password even when the core posts response is correct.
Core sends no-cache headers for singular posts with a non-empty\npost_password, whether currently locked or unlocked. Preserve them. A page\ncache or CDN that serves before WordPress runs must also bypass protected URLs\nor requests carrying a wp-postpass_ cookie; never let unlocked HTML populate\nan anonymous cache key.
Apply the same rule to REST responses, fragments, edge rendering, service\nworkers, and headless caches. Purging after a password change does not fix a\ndesign that mixes locked and unlocked variants.
\nTest observable behavior with a temporary protected post:
\nview versus permitted\nedit context; comment endpoints where applicable.Distinguish a content leak from a UI mismatch. Report file/line, post/output\nsurface, request identity and cookie/password state, cache layer, exposed data,\nand the smallest policy-preserving fix.
\nDo not label the core form's missing nonce as CSRF by itself. The handler changes\nonly the visitor's post-password cookie and does not grant server-side user\nprivileges. If a customization adds account, entitlement, or persistent state\nchanges, protect those mutations separately.
\npost_password_required() before every custom\noutput surface.post_password in public API\nresponses.wp-rest-api for a custom protected REST resource or headless route.wp-security-audit for capability, output, custom download, and\nendpoint review around the gate.post_password_required(),\nget_the_password_form(),\nand the posts REST endpoint.wp-includes/post-template.php, wp-login.php, wp-includes/class-wp.php, wp-includes/class-wp-query.php, wp-includes/comment.phpwp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php, wp-includes/rest-api/endpoints/class-wp-rest-comments-controller.phpwp-includes/block-bindings/post-meta.php, wp-includes/block-bindings/post-data.php