Session-Security Testing Skill: Review Creation, Revocation, Expiry, and Device Boundaries

Session security fails in the transitions: after login, after a password change, when a second device appears, or when a session should have expired but still carries authority.

Why this Skill is needed

The Session-Security Testing Skill prepares evidence-bounded scenarios for session creation, fixation, expiry, revocation, concurrency, and cross-device boundaries. It keeps a design claim separate from an executed security result.

What the Skill does

A session rule is only useful when its lifecycle and invalidation boundary are observable.

Use this Skill to review session behavior in an isolated environment with synthetic accounts. It identifies security concerns and validation actions without logging into production, reading credentials, or claiming the system secure.

A useful finding names the session state, actor and device, trigger, expected token or authority change, evidence, owner, close condition, and safe validation method.

Use it when authentication changes, refresh-token behavior changes, logout or password-reset flows are redesigned, or cross-device policy is unclear.

What it does not do

The Session-Security Testing Skill can organize material, evidence, and next actions for a session lifecycle review. It does not replace:

Confirmation of rules, scope, and risk by the accountable domain owner.
A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
Authorization for release, compliance, production actions, or residual-risk acceptance.
A Human decision when supplied sources conflict.

What it checks

The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:

Focus	Question before analysis	Handoff output
Session lifecycle	Session state, trigger, actor, and device	Source and applicability
Security concern	Unexpected authority, fixation, stale access, or cross-device leak	Evidence state
Expected boundary	What should expire, rotate, revoke, or remain	Policy and owner
Validation action	Safe replay and evidence needed	Synthetic account and cleanup

If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.

Audit inputs before you start

Before reviewing the session lifecycle, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.

State	Meaning	How this Skill should handle it
known	Directly supported by the supplied material	Keep the source, version, and time with the judgment
missing	Needed for this pass but not supplied	Name the smallest evidence action and limit the conclusion
conflicting	Sources disagree	Show both sources and route the conflict to an owner
stale	Present but outside the relevant version or time window	Mark freshness; old evidence is not current proof
out_of_scope	Related but excluded from this pass	Keep the boundary explicit
assumptions	Temporarily adopted to continue analysis	State how and when the assumption will be checked

Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.

From problem to structured Finding

Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.

Keep the decision layers separate

For a session lifecycle review, do not compress four different judgments into “recommended to pass”:

Layer	How to write it	Application here
Fact	What the supplied material directly shows	Cite the source, version, input, or run record for the focus
Evidence-backed Inference	What several facts support together	Show the inference chain and retain uncertainty
Recommendation	The smallest next action	Name the evidence, review, execution, or regression path
Human Decision	What an accountable person must decide	Leave scope, risk acceptance, resources, and release meaning to the owner

A complete case

This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.

Input

Material	What to provide	What to do when it is missing
Session model	Creation, refresh, expiry, logout, password reset, and revocation rules	Keep undocumented transitions open
Actors and devices	User roles, browser/device classes, concurrency, and tenant scope	Mark boundaries missing
Token evidence	Redacted claims, cookie flags, IDs, timestamps, and server records	Do not provide live tokens
Validation environment	Synthetic accounts, isolated staging, logs, and cleanup	No production login

Use a request like this:

Use the session-security-testing Skill.

Task: Review whether a password reset revokes browser and mobile sessions, while keeping one approved recovery device active.
Inputs: [session policy, token metadata, reset flow, device rules, staging logs, synthetic accounts]
Scope: [web and mobile staging]
Constraints: [no real credentials, no production access]

Cover creation, fixation, expiry, revocation, concurrency, and cross-device boundaries. Keep unsupported security claims pending.

Analysis

Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.

Finding

Focused example: Check reset revocation across web and mobile

A password reset revokes the web cookie but leaves a mobile refresh token usable. The Skill should record the cross-device revocation gap, preserve the approved recovery-device exception if one exists, and propose a synthetic-account replay with token timestamps and server-side revocation evidence.

Track refresh credentials separately from access tokens that were already issued; they may follow different invalidation contracts:

Credential state	Compare	Do not infer
Refresh token	Redacted labels before and after the password change, issue time, server-side revocation state, and later refresh records	A successful logout response does not prove the refresh token was revoked
Already-issued access token	Expiry claims, resource-request result, and the applicable revocation rule	Revoking a refresh token does not prove that an existing access token stops working immediately
Cross-device session	Web cookie, mobile refresh credential, recovery-device exception, and server session records	One client’s result does not establish the result for every device

If policy does not say what happens to existing access tokens after a password change, leave that rule open. Do not invent a lifetime or claim immediate invalidation. A validation candidate should still use a synthetic account and retain redacted credential labels, a timeline, and server-side evidence.

The review prepares security scenarios and evidence checks. It cannot prove exploit success, absence of vulnerability, or release security without an authorized run.

Example finding: turn one problem into a handoff

The field example below shows the recording pattern; it is not an execution result.

If the supplied material does not define the expected session state after a password reset across web and mobile, record the finding like this. It does not invent the missing rule or turn missing evidence into a failure.

Field	Example wording
Source and scope	Record the requirement, version, environment, and web/mobile session-revocation rule
Finding	The expected cross-device session state after a password reset is not yet traceable to evidence
Evidence state	missing / assumptions; use conflicting when sources disagree
Impact and priority	Name the affected user, journey, or delivery decision without inflating severity
Owner and Human decision	Ask the product, engineering, security, or test owner to confirm the rule and trade-off
Action and close condition	Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed
Validation	Name one repeatable check, query, or run and retain the raw artifact

The point is to let the next person walk from the finding back to the source and run an action that can change the decision.

Decision

The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.

Validation

Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.

How a Finding enters the next stage

Handoff output

Output field	Why it exists	Example status
Session lifecycle	Session state, trigger, actor, and device	Source and applicability
Security concern	Unexpected authority, fixation, stale access, or cross-device leak	Evidence state
Expected boundary	What should expire, rotate, revoke, or remain	Policy and owner
Validation action	Safe replay and evidence needed	Synthetic account and cleanup

Every conclusion should point to a source, evidence state, and next action. If evidence is missing, use pending, blocked, unassessed, or NOT_SCORED instead of filling the gap with confidence.

Next-stage route

At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.

How to prepare better input

Provide the session lifecycle, token types, cookie and storage policy, actor/device matrix, reset/logout rules, environment, synthetic accounts, and cleanup plan. Redact token values.

A useful handoff includes input versions, scope, time window, evidence index, assumptions, Human decision boundary, and the smallest validation action.

Working with other Skills

Authentication Testing: https://inaodeng.com/en/qaskills/authentication-testing/ — checks identity establishment and login flows.
Authorization Testing: https://inaodeng.com/en/qaskills/authorization-testing/ — checks resource access after session state changes.
Secrets-Exposure Review: https://inaodeng.com/en/qaskills/secrets-exposure-review/ — reviews token and log exposure boundaries.

Common traps

Testing logout only in one browser and missing refresh tokens or mobile sessions.
Checking token expiry time without checking server-side revocation and resource authorization.
Using a real user account or live token to prove a security boundary.

Install and invoke

npx skills add naodeng/awesome-qa-skills --skill session-security-testing

Installation and troubleshooting:

Use the session-security-testing Skill.
Include objective, scope, versions, evidence paths, constraints, and decision boundary.
Audit inputs first, preserve evidence states, and finish with owner, close condition, and validation method.

FAQ

Is a short token lifetime enough?

No. Expiry, rotation, revocation, storage, concurrency, and resource checks all contribute to session security.

Can I reuse a production account in staging?

No. Use synthetic accounts with explicit roles and cleanup; do not move real credentials across environments.

Will this Skill log in or replay tokens directly?

No. It organizes scenarios and validation suggestions from supplied material. An authorized tester must perform any execution in an isolated environment.

The Skill is easiest to review when applied to one redacted project artifact and kept with its source evidence. Validate the uncertain part first, then expand only when the evidence supports it.

References

Static plans, file presence, and dry runs keep their evidence state. They do not become runtime proof, an all-passed claim, or release approval.

Session-Security Testing prompt (execution contract): https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/session-security-testing/prompts/session-security-testing.md
Session-Security Testing Skill source: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/session-security-testing
Session-Security Testing details: https://inaodeng.com/en/qaskills/session-security-testing/
Awesome QA Skills on GitHub: https://github.com/naodeng/awesome-qa-skills