fix: force the Secure cookie flag when SameSite=None applies

[kishore7snehil]

Changes

When responseMode is form_post, both CookieStore and SessionStore unconditionally set the cookie SameSite attribute to None, because a cross-origin POST callback requires it. However, the secure flag was still taken from cookieSecure (default false), so the SDK could emit a SameSite=None cookie without Secure. Browsers reject a SameSite=None cookie that does not also carry Secure (RFC 6265bis), so this combination results in the cookie being dropped on modern browsers.

This PR forces the Secure flag on whenever the resolved SameSite is None:

🔒 Security Fix:

• CookieStore::getCookieOptions() now sets secure to true when the resolved samesite value is None, after the existing SameSite normalization, so both form_post and an explicit cookieSameSite of None are covered
• SessionStore::start() applies the same rule to the native PHP session cookie params, forcing secure on when SameSite=None is in effect
• cookieSecure still defaults to false and is otherwise unchanged. The $cookieSecure documentation now notes that Secure is forced on when SameSite=None applies and recommends enabling it in production

Applications using the default query response mode are unaffected, as their cookies keep the same attributes. For form_post applications, the session and transient cookies now always carry Secure and are therefore only sent over HTTPS. Such deployments should serve the callback over HTTPS.

References

N/A

Testing

• Added SameSite=None forces the Secure flag on even when cookieSecure is false to the CookieStore unit tests, asserting that form_post yields samesite=None with secure=true

• This change adds unit test coverage

• This change has been tested on the latest version of the platform/language

Contributor Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 code of conduct