According to this site, it seems it is a matter of PHP 7.3. As of the voting results, a more general extension to cookie-related functions is being implemented + there might be also a new key in php.ini file.
But as Marc B already wrote, you can use header() function call instead, I would do it in some file with used for inclusion of other initial stuff.
[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:
2.2 Setting SameSite cookies using Nginx configuration
location / {
# your usual config ...
# hack, set all cookies to secure, httponly and samesite (strict or lax)
proxy_cookie_path / "/; secure; HttpOnly; SameSite=strict";
}
Same here, this also will update all your cookies with SameSite=Lax flag
Adding to the answer by Marty Aghajanyan (because apparently I can answer, but not yet comment)
Doing it in Apache via mod_headers in conjunction with PHP was not working for me in Apache 2.4.29 (Ubuntu). In reviewing the docs (http://www.balkangreenfoundation.org/manual/en/mod/mod_headers.html) I noticed the "always" condition has certain situations where it does not work from the same pool of response headers. Thus the following worked for me to set the SameSite parameter. (Tho in my case I am setting None for the recent Chrome 80 update)
If a cookie is needed to be sent cross-origin, opt out of the SameSite restriction by using the None directive. The None directive requires that the Secure attribute also be used.
The examples that are setting SameSite to None or Lax are only appropriate for cross-domain scenarios. If your code isn't cross-domain, use Strict.