PHP Site AuditWeb security basics
PHP site cookies: Secure, HttpOnly, and SameSite in context
For a session cookie, Secure limits sending it to HTTPS connections, HttpOnly keeps browser scripts from reading it directly, and SameSite controls some cross-site sending behavior. These attributes reduce specific risks; they do not replace server-side session protection, CSRF defenses, or a patched PHP runtime.
What the three attributes mean
Secure tells a browser to send the cookie only over an encrypted HTTPS connection. HttpOnly prevents ordinary client-side script access through browser cookie APIs, which helps limit some session theft after a script injection. SameSite=Lax or Strict limits some cross-site cookie sending. SameSite=None is intended for cross-site use and requires Secure in modern cookie behavior.
OWASP describes these as protections for the session identifier, with tradeoffs. Strict can disrupt legitimate navigation from another site; Lax permits some top-level safe navigations. SameSite should be defense in depth and does not generally replace a CSRF token for state-changing requests.
A missing cookie is not automatically a finding
A public homepage may not issue a session cookie. A Set-Cookie header sampled on one path may be an analytics or preference cookie rather than the authenticated session. A useful assessment names the observed cookie and path, and avoids claiming every application cookie is insecure based on an unrelated response.
Test the login and account flows in an authorized environment, inspect the actual session cookie attributes, and confirm the server invalidates sessions on logout and applies appropriate expiration. Use the application's framework and host documentation for the configuration that controls those cookies.
Keep runtime patching separate
Cookie flags protect browser-to-site session handling. They do not remediate a flaw in PHP's request parser or memory management. For PHP2Shell, verify the server-side runtime against the official PHP or vendor security release. A good external report distinguishes cookie configuration from runtime patch status.
Inspect cookies during login, account changes, payment handoff and logout, including redirects across trusted domains. Confirm that session identifiers rotate at appropriate privilege changes and that application authorization still protects sensitive actions; cookie flags do not replace those controls.
Document which cookie belongs to authentication, analytics or a third-party integration before changing attributes; that makes regression reports actionable and helps avoid weakening a sensitive session cookie to repair an unrelated flow.
Common questions
Do Secure, HttpOnly and SameSite prove a session is safe?
No. They affect cookie transport and browser access; session design, authorization and PHP patching are separate.
Should every cookie use the same SameSite value?
Not always. Select attributes for the site's login, payment and cross-site flows, then test real browser behavior.
Can a public check see every cookie?
It sees cookies returned on sampled requests; authenticated or conditional flows may issue others.