wstg-session-management

Tests web application session management against the nine OWASP WSTG-SESS test cases.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill wstg-session-management-maicongambini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wstg-session-management
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/wstg-session-management
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill wstg-session-management-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web application session management flaws are the most common path to account takeover, yet testers often miss critical checks like token renewal on login, server-side logout invalidation, or cookie attribute misconfigurations. This Skill provides the complete OWASP WSTG v4.2 session management methodology so penetration testers systematically cover all nine WSTG-SESS test cases. ## Core Features & Use Cases - Full WSTG-SESS Coverage: Step-by-step procedures for session schema analysis, cookie attributes, session fixation, exposed session variables, CSRF, logout, timeout, session puzzling, and session hijacking. - Concrete Test Procedures: Each test case includes objectives, hands-on testing steps, what to look for, and remediation guidance aligned with OWASP recommendations. - Use Case: During a web application penetration test, use this Skill to verify whether session tokens are renewed after authentication (WSTG-SESS-03), then confirm the logout function invalidates sessions server-side by re-injecting the old cookie (WSTG-SESS-06). ## Quick Start Use the wstg-session-management skill to test whether this application's session cookie is renewed after login and whether the old session remains valid after logout.

Frequently Asked Questions about wstg-session-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for session fixation vulnerabilities?

Record the session cookie before authentication, log in, then check whether the cookie value changed. If the same token persists after login, or the pre-authentication token still grants access, the application is vulnerable to session fixation (WSTG-SESS-03).

How to test if logout invalidates the session server-side?

Save the authenticated session cookie, invoke logout, then restore the old cookie value and request an authenticated page. If access is granted, the application only cleared the client-side cookie without server-side session invalidation (WSTG-SESS-06).

What cookie attributes should session cookies have?

Session cookies should set Secure, HttpOnly, a restrictive Path, no Domain attribute, and SameSite=Strict or Lax. The strongest configuration uses the __Host- prefix: Set-Cookie: __Host-SID=<token>; path=/; Secure; HttpOnly; SameSite=Strict.

Does SameSite=Lax fully prevent CSRF attacks?

No. SameSite provides defense-in-depth but does not replace anti-CSRF tokens. State-changing endpoints still need unique, unpredictable tokens validated server-side, plus Origin and Referer header checks for sensitive operations.

Why is session puzzling hard to detect in black-box testing?

Session puzzling depends on accessing pages in unanticipated orders, where variables set by public endpoints are trusted by privileged ones. Black-box testers must enumerate entry and exit points manually, so source code review is recommended for reliable detection.