HTTPOnly attribute for WP Test Cookies

[earthman100]

This code does not set the HTTPOnly attribute for the test cookies.

They continue to be flagged in automated security scans of our sites.

Is there any reason for not setting these, or providing a hook to allow user control of the attributes?

wp-login.php

<?php


// Set a cookie now to see if they are supported by the browser.
$secure = ( 'https' === parse_url( wp_login_url(), PHP_URL_SCHEME ) );
setcookie( TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN, $secure );

if ( SITECOOKIEPATH !== COOKIEPATH ) {
        setcookie( TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN, $secure );
}

if ( isset( $_GET['wp_lang'] ) ) {
        setcookie( 'wp_lang', sanitize_text_field( $_GET['wp_lang'] ), 0, COOKIEPATH, COOKIE_DOMAIN, $secure );
}

Suggested modification (or add a hook for the final attribute):

<?php


// Set a cookie now to see if they are supported by the browser.
$secure = ( 'https' === parse_url( wp_login_url(), PHP_URL_SCHEME ) );
setcookie( TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN, $secure, true );

if ( SITECOOKIEPATH !== COOKIEPATH ) {
        setcookie( TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN, $secure, true );
}

if ( isset( $_GET['wp_lang'] ) ) {
        setcookie( 'wp_lang', sanitize_text_field( $_GET['wp_lang'] ), 0, COOKIEPATH, COOKIE_DOMAIN, $secure, true );
}

When running WordPress at a regulated organization security audits routinely flag security issues when PHP creates cookies without the HttpOnly argument set to true. While this can't be done for cookies that are used client-side, it can be safely enabled for these server-side only cookies.

• TEST_COOKIE
• wp-postpass_{HASH}

I've tested this on the latest WordPress trunk with a server stack that mirrors Kinsta and WPEngine. This stack passes 100% of Site Health checks, and is running on the following:

Darwin 23.6.0 x86_64
nginx/1.25.5
PHP 8.3.7 (support 64bit values)
Zend OPcache v8.3.7
mysql 8.3.0 / mysqlnd 8.3.7
8.7.1 (SecureTransport) OpenSSL/3.3.0

Originally reported by earthman100

Are these test actions reliable?

I re-triggered tests with a --no-commit that changed nothing, and I see completely different results?

1. ​First test run shows 10 errors with specific PHP versions and MySQL/MariaDB combinations
2. ​First test run shows 7 entirely different errors related to SCRIPT_DEBUG and applications-passwords.test.js

Not sure what was up with those performance tests but I merged the trunk branch into this and they seem pretty stable again.

[johnbillion]

In 59671:

Security: Set the HttpOnly flag for the test cookie and the wp_lang cookie on the login screen.

These cookies are only accessed server-side and don't need to be exposed to JavaScript in the browser.

Props earthman100, kevinlearynet

Fixes #61322

@johnbillion

Thanks! Glad the unit tests work on trunk w/o issues