Session cookies are the keys to your school's admin panels, portals, and CMS. Missing Secure and HttpOnly flags make them easy to steal. Here's what each flag does and how to set them.
When a staff member logs into your school's CMS, admin panel, or student portal, the server creates a session cookie — a small token stored in the browser that proves "this person is logged in." Every subsequent request from that browser includes this cookie so the server knows who they are.
If an attacker steals a session cookie, they don't need the user's password. They simply use the stolen cookie to impersonate that user — including full admin access if the victim is an administrator.
Set-Cookie: session=abc123; Secure
The Secure flag tells the browser: "Only send this cookie over HTTPS connections, never over HTTP."
Without it, the session cookie is transmitted in plain text whenever the browser makes an HTTP request — which can happen even on HTTPS sites (e.g., mixed content, HTTP subdomains). An attacker on the same school Wi-Fi can capture it.
Set-Cookie: session=abc123; HttpOnly
The HttpOnly flag tells the browser: "This cookie cannot be accessed by JavaScript."
Without it, any JavaScript running on the page — including injected malicious scripts from an XSS attack — can read the cookie with document.cookie and send it to an attacker's server. HttpOnly makes this impossible.
Set-Cookie: session=abc123; SameSite=Strict
The SameSite flag controls when the browser sends the cookie in cross-site requests, preventing Cross-Site Request Forgery (CSRF) attacks.
| Value | Behavior |
|-------|---------|
| Strict | Cookie never sent in cross-site requests (most secure) |
| Lax | Cookie sent only on top-level navigation (safe default) |
| None | Cookie sent in all cross-site requests (requires Secure) |
A properly secured session cookie looks like this:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax
Missing HttpOnly: An attacker injects a script via an XSS vulnerability in a comment field or contact form. The script reads document.cookie and sends the admin's session token to attacker.com. The attacker now has full admin access to the school's CMS.
Missing Secure: A staff member visits the school site from a coffee shop. The browser sends their session cookie over an HTTP request (perhaps a redirect or mixed content load). An attacker on the same Wi-Fi captures it.
Missing SameSite: A staff member clicks a link in a phishing email. The attacker's page secretly submits a form to your school's admin panel. Because the cookie is sent with the cross-site request, the action is performed as the logged-in user.
// In php.ini or at the top of your script:
ini_set('session.cookie_secure', 1);
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_samesite', 'Lax');WordPress respects PHP session settings. For the wordpress_logged_in cookie, use a plugin like WP Cookie Consent or add to wp-config.php:
define('COOKIE_SECURE', true);Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
proxy_cookie_flags ~ Secure HttpOnly SameSite=Lax;
Interactive Cookie Demo: See JavaScript read a session cookie when HttpOnly is missing (XSS cookie theft), then watch a hidden form auto-submit using a live session when SameSite is absent (CSRF). Two attacks, one demo.
The Site Scanner inspects your school site's cookies and flags any missing Secure, HttpOnly, or SameSite attributes.