Guide 3: Web Security Headers and Cookies
A beginner-friendly practical guide for learning how HTTP security headers, cookies, user agents, and browser controls help protect web applications.
In this guide, you will inspect common web security headers and cookies. You will learn how browsers use headers and cookie attributes to reduce security risks such as cross-site scripting, session theft, insecure cookie transmission, and accidental exposure of sensitive values.
Completion status
Overview
Learn how headers and cookies shape browser security
Web applications communicate with browsers using HTTP requests and responses. These messages often include headers and cookies. Security headers can tell the browser what is allowed, blocked, or restricted. Cookies can store session identifiers and user preferences, but weak cookie settings can create security and privacy risks.
Explain what HTTP headers are.
Understand why security headers help protect web applications.
Read and interpret a Content Security Policy.
Identify risky CSP values such as unsafe-inline, unsafe-eval, and wildcard sources.
Parse cookies and identify important cookie attributes.
Explain the purpose of Secure, HttpOnly, SameSite, Path, Domain, and Expires or Max-Age cookie attributes.
Understand why session cookies and tokens should be protected.
Recognise why headers and cookies are important in web security investigations.
Important safety note
Use only fake examples in this guide
Do not paste real session cookies, real authentication tokens, university login cookies, work cookies, or private headers into this guide. Use only fake examples or the sample values provided in the tasks.
How to use this guide
Work through each browser security example carefully
- Read each task carefully.
- Use only the sample headers and cookies provided in this guide.
- Open the linked MuhammadLab tool when instructed.
- Copy your result or observation into the answer box.
- Think about what each security setting means.
- Save your answers locally.
- Complete the quiz.
- Mark the guide as complete when finished.
Tools used in this guide
Open the existing MuhammadLab tools as you work
Task 1
Understand basic HTTP headers
Read the sample response headers and identify which header controls content type, caching, MIME handling, and framing behaviour.
Sample HTTP response headers
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Cache-Control: no-store X-Content-Type-Options: nosniff Referrer-Policy: no-referrer X-Frame-Options: DENY
Tool to use
No tool required for this task.
Expected student action
Identify the content-type header, the no-cache header, the MIME-sniffing control, and the clickjacking-related header.
Reflection question
Why do browsers need instructions from response headers?
Optional hint
Headers provide metadata and security instructions that affect how the browser handles the response.
Task 2
Inspect a Content Security Policy
Use the CSP Policy Viewer to inspect a sample CSP and summarise what it allows and blocks.
Sample CSP
default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none';
Tool to use
Expected student action
Paste a short summary of what this policy allows and what it blocks.
Reflection question
What does object-src 'none' help prevent?
Optional hint
It blocks plugins and embedded objects, reducing attack surface.
Task 3
Identify risky CSP values
Inspect a weaker CSP and identify risky values or patterns that reduce browser protection.
Weaker CSP example
default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval' *; style-src 'self' 'unsafe-inline' *; img-src * data:; frame-ancestors *;
Tool to use
Expected student action
Identify at least three risky values or patterns in the policy.
Reflection question
Why can unsafe-inline, unsafe-eval, and wildcard sources increase risk?
Optional hint
They may allow scripts or resources from less controlled places, weakening protection against attacks such as XSS.
Task 4
Parse a Set-Cookie header
Use the Cookie Parser to inspect a sample Set-Cookie header and record the key attributes.
Sample Set-Cookie header
session_id=abc123xyz789; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
Tool to use
Expected student action
Write the cookie name, value, path, whether HttpOnly is enabled, whether Secure is enabled, the SameSite value, and the Max-Age value.
Reflection question
Why are HttpOnly and Secure important for session cookies?
Optional hint
HttpOnly reduces JavaScript access to the cookie. Secure tells the browser to send it only over HTTPS.
Task 5
Compare strong and weak cookie settings
Use the Cookie Parser to compare a stronger cookie example with a weaker one and decide which is safer.
Compare these cookies
Strong example: auth_token=fake_token_123; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=1800 Weak example: auth_token=fake_token_123; Path=/; SameSite=None
Tool to use
Expected student action
Explain which cookie is safer and why.
Reflection question
What security attributes are missing from the weak cookie?
Optional hint
Look for Secure, HttpOnly, and SameSite settings.
Task 6
Understand SameSite behaviour
Read three SameSite examples and explain, in simple words, how their behaviour is different.
SameSite examples
SameSite=Strict SameSite=Lax SameSite=None; Secure
Tool to use
Expected student action
Explain in simple words how Strict, Lax, and None differ.
Reflection question
Why is SameSite useful for reducing cross-site request risks?
Optional hint
SameSite controls when cookies are sent with cross-site requests.
Task 7
Inspect a user-agent string
Use the User-Agent Parser to inspect a sample user-agent string and record what it reveals.
Sample user-agent string
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Tool to use
Expected student action
Write the browser family, operating system, device type if shown, and rendering engine if shown.
Reflection question
Why might user-agent strings be useful in logs or investigations?
Optional hint
They can help identify browsers, operating systems, bots, devices, and suspicious access patterns, but they can also be spoofed.
Task 8
Redact sensitive web logs
Use a MuhammadLab redaction tool to clean a fake web log before sharing it.
Fake web log
192.168.1.15 - - [12/May/2026:10:20:31 +1000] "GET /dashboard HTTP/1.1" 200 Cookie: session_id=abc123xyz789; auth_token=fake_secret_token Authorization: Basic dXNlcjpwYXNzd29yZA== User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) email: student@example.com
Expected student action
Paste the redacted output into the answer box and keep only the information that is safe to share.
Reflection question
Which values should be removed or masked before sharing logs?
Optional hint
Session IDs, auth tokens, Authorization headers, emails, and other identifiers should usually be redacted.
Extension
Optional: decode the sample Basic Authorization value
If the Basic Auth Encoder supports decoding, inspect the sample Authorization value from Task 8 and explain why Basic Auth values should not be shared publicly.
Mini summary
What this guide connected together
Common mistakes
Watch for these beginner traps
Mistake 1: Thinking cookies are always safe because they are small text values.
Mistake 2: Sharing real session cookies or tokens in screenshots or logs.
Mistake 3: Forgetting to use Secure on sensitive cookies.
Mistake 4: Forgetting to use HttpOnly on session cookies.
Mistake 5: Using unsafe-inline and unsafe-eval without understanding the risk.
Mistake 6: Trusting user-agent strings completely even though they can be spoofed.
Mistake 7: Posting Authorization headers in public support requests or GitHub issues.
Knowledge check
Quick quiz with immediate feedback
Answer the questions below to check your understanding of web headers, cookies, CSP, and safe log sharing.
1. What is the main purpose of HTTP response headers?
2. What does Content Security Policy mainly help control?
3. Which CSP value can be risky if used carelessly?
4. What does the HttpOnly cookie attribute help prevent?
5. What does the Secure cookie attribute mean?
6. Why can user-agent strings be useful but unreliable?
7. Which value should usually be redacted before sharing logs?
Privacy note
Your answers stay local to this browser
This guide is designed for browser-based learning. Your answers and completion status are saved locally in your browser using localStorage. Do not enter real session cookies, real authentication tokens, real Authorization headers, university credentials, or work credentials.
Completion
Finish the lab and save your progress locally
Next
Guide 4: Log Redaction and IOC Extraction
This next guided lab continues the path with redaction practice, IOCs, and investigation-ready log handling.