ASVS 5.0 V8.1.3 (Level 3) requires documentation that lists every environmental and contextual attribute the application uses in security decisions, including time of day, user location, IP address and device, for both authentication and authorization.
Why it matters
Contextual rules are easy to add and easy to forget. A geo block added during an incident can lock out a traveling executive months later, and no one knows where the rule lives. A list makes the behavior reviewable and the data collection justifiable.
How to implement it
Maintain an inventory with one row per attribute:
| Attribute | Source | Used for | Stored? | Owner |
|---|---|---|---|---|
| Source IP | Load balancer header | Block known bad ranges, new IP alert | 90 days | platform |
| Country | IP lookup | Step up when it changes | 30 days | appsec |
| Device ID | Signed cookie | Remember trusted device | Until revoked | identity |
| Local hour | Server clock | Admin actions blocked outside hours | No | appsec |
Note trust issues, too. A forwarded IP header is only reliable if your proxy sets it and strips client supplied values.
How to test it
Grep the code for reads of these inputs (headers, geo libraries, device cookies) and compare against the inventory. Any attribute used but not listed is a documentation gap.
Common mistakes
- Using an attribute in a rule and never recording it.
- Trusting raw forwarded headers.
- Keeping contextual data longer than the document says.
Quick check
Do I need this if I only use passwords?
If no contextual attribute influences any decision, the list is simply empty. State that explicitly.
