Viewed   247 times

I recently read "RFC 6265" on the attribute "Same Site", I looked at some articles that talked about that in April 2016, "same-site" attribute has been implemented for Chrome 51 and Opera 39 ...

I wonder if current PHP supports creating cookies with this attribute?


  • Feature documentation on Chrome’s
  • HTTPbis draft first adopted by Chrome
  • Latest HTTPbis draft



[Important update: As @caw pointed out below, this hack WILL BREAK in PHP 7.3. Stop using it now to save yourself from unpleasant surprises! Or at least wrap it in a PHP version check like if (PHP_VERSION_ID < 70300) { ... } else { ... }.]

It seems like you can abuse the "path" or "domain" parameter of PHP's "setcookie" function to sneak in the SameSite attribute because PHP does not escape semicolons:

setcookie('samesite-test', '1', 0, '/; samesite=strict');

Then PHP sends the following HTTP header:

Set-Cookie: samesite-test=1; path=/; samesite=strict

I've just discovered this a few minutes ago, so please do your own testing! I'm using PHP 7.1.11.

Saturday, September 10, 2022

The issue is also adressed here:

See comment by jah:

If you want to restrict the cookie to a single host, supply the domain parameter as an empty string

You could also try as the domain. The trailing dot will allow a cookie for all subdomains for and could overwrite the www.-cookie, but I'll go with the above solution first.

Thursday, November 24, 2022

Make sure you have a domain that is known by both server and client. echo $_SERVER['HTTP_HOST'] should tell you the exact same domain that your browser has. If not, cookie will not be accepted by the browser.

Make sure your server and client time is perfectly correct. Browser will reject a cookie with a wrong datetime.

Do not write any other code and just do:

$cookie_name = "user";
$cookie_value = "John Doe";
setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day 
// expiration
echo date("H:i:s d.m.Y")."<br>";
echo $_SERVER['HTTP_HOST']."<br>";

and refresh the page twice.

Also check out manual at:

Wednesday, October 19, 2022
  • For your cookies, see this answer.
  • For PHP's own session cookie (PHPSESSID, by default), see @richie's answer

The setcookie() and setrawcookie() functions, introduced the httponly parameter, back in the dark ages of PHP 5.2.0, making this nice and easy. Simply set the 7th parameter to true, as per the syntax

Function syntax simplified for brevity

setcookie(    $name, $value, $expire, $path, $domain, $secure, $httponly )
setrawcookie( $name, $value, $expire, $path, $domain, $secure, $httponly )

In PHP < 8, specify NULL for parameters you wish to remain as default.

In PHP >= 8 you can benefit from using named parameters. See this question about named params.

setcookie( $name, $value, httponly:true )

It is also possible using the older, lower-level header() function:

header( "Set-Cookie: name=value; httpOnly" );

You may also want to consider if you should be setting the secure parameter.

Wednesday, December 7, 2022

Don't store the password in the cookie, hashed or not. In fact, there's no reason to store anything sensitive in the cookie. All you need to do is map a 128-bit (or larger) random id to a user account in your database, and store that id in the cookie. There is no way somebody is going to guess a valid id by remote brute force, especially if you have lock-outs in place.

If someone were to gain access to the cookies and they copy them to a different computer, and then try accessing the website from that computer, theoretically, it will automatically log them in to that user's account, is this not a security issue?

Yes. That's the downside to the feature. However, if your website detects new IP address (particularly from different countries) and requires a second step (text a code to a mobile device, etc), then you take care of this problem along with the general problem of a stolen password. (This of course doesn't help prevent local network attacks, like an insecure public wifi.)

A more convenient solution is to require the "remember me" cookie to use SSL. That way a hacker would not ever see the cookie in plain text transmission, and a local attack would probably be required. (And if such, the remember me cookie is probably the least of the user's concerns.)

they can effectively get access to any account they want, rendering the whole password-hashing process as useless.

Yes, and no. If you use the technique I described (random id) then they can only access accounts that have a "remember me" cookie. But that said, if they have access to your database, they can brute force any account they want. Even salted passwords are easy to crack locally if the password itself is weak.

Also, you can consider the "remember me" login to be a half-login. Access to purchase something, change an email address, etc, would still require a password to be entered. Doing harmless things like posting on a message board could be done without the password.

Finally, note that a PHP session cookie is nothing more than a temporary "remember me" token! So much of this applies to the concept of session hijacking. The "remember me" token simply adds a bigger window of opportunity.

So in short: don't store anything sensitive in the cookie, require SSL for the cookie, and if possible, implement multi-factor authentication ... especially for admin accounts.

Thursday, October 6, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :