Cookie Security Flags: Protecting Session Cookies on School Sites
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.
What Are Session Cookies?
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.
The Three Critical Cookie Flags
1. Secure Flag
```
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.
2. HttpOnly Flag
```
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.
3. SameSite Flag
```
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) |
All Three Together
A properly secured session cookie looks like this:
```
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax
```
Real Risks for Schools
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.
How to Fix Cookie Flags
PHP (session cookies)
```php
// 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
WordPress respects PHP session settings. For the wordpress_logged_in cookie, use a plugin like WP Cookie Consent or add to wp-config.php:
```php
define('COOKIE_SECURE', true);
```
Apache (add flags to all cookies via header manipulation)
```apache
Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
```
Nginx
```nginx
proxy_cookie_flags ~ Secure HttpOnly SameSite=Lax;
```
Check Your Site
The Site Scanner inspects your school site's cookies and flags any missing Secure, HttpOnly, or SameSite attributes.
Related Resources
- Content Security Policy — prevents XSS attacks that target cookies
- HTTPS and SSL Explained — required for the Secure flag to be meaningful
- School Cybersecurity Checklist — full web security checklist