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