OWASP ASVS Reference (Level 1 -- Curated for Todorovi Wines)
This is a curated subset of OWASP Application Security Verification Standard (ASVS) v4.0 Level 1 requirements relevant to the consumer web platform and the restaurant API. Level 1 is the minimum verification level for any internet-facing application.
Your exploitation findings are direct evidence of specific ASVS failures. Map them.
V2: Authentication
V2.1.1 -- Verify that user set passwords are at least 12 characters in length
Verification method: Check application's password policy configuration. Status guidance: If the application accepts passwords shorter than 12 characters, this fails.
V2.1.7 -- Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords
Verification method: Attempt account creation with a known breached password (e.g., "password123"). Status guidance: If accepted, this fails.
V2.2.1 -- Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks
Verification method: Attempt multiple failed logins. Check for rate limiting or lockout. Status guidance: If the API has no rate limiting (a hidden constraint), this fails.
V3: Session Management
V3.2.1 -- Verify the application generates a new session token on user authentication
Verification method: Log in and check if the session ID changes from the pre-authentication value. Status guidance: If the same session token persists before and after login, this fails.
V3.4.1 -- Verify that cookie-based session tokens have the Secure attribute set
Verification method: Inspect cookies in browser developer tools. Status guidance: If session cookies lack the Secure flag, this fails.
V5: Validation, Sanitization, and Encoding
V5.2.4 -- Verify that structured data is strongly typed and validated against a defined schema
Verification method: Send malformed JSON to API endpoints. Check if the API accepts unexpected fields (mass assignment). Status guidance: If the API accepts fields not in the expected schema, this fails. Your mass assignment testing in Unit 6 provides direct evidence.
V5.3.4 -- Verify that data selection or database queries use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks
Verification method: Your SQL injection testing provides direct evidence. If injection succeeds, this fails. Status guidance: The SQL injection you confirmed in Unit 5 is direct evidence of this ASVS failure.
V5.3.7 -- Verify that the application protects against XSS by using output encoding
Verification method: Your XSS testing provides direct evidence. If XSS payloads execute, this fails. Status guidance: The XSS findings from Unit 5 map directly to this requirement.
V7: Error Handling and Logging
V7.1.1 -- Verify that the application does not log credentials or payment details
Verification method: Review application logs for sensitive data. Status guidance: If stored card details (last-four digits, expiration) appear in logs, this is a concern. Check whether the hidden constraint about stored card data shows up in logging.
V7.4.1 -- Verify that a generic message is shown when an unexpected or security sensitive error occurs
Verification method: Trigger errors through invalid input. Check if stack traces or database errors are exposed to the user. Status guidance: If the application returns verbose error messages including technology details, this fails.
V13: API and Web Service
V13.1.1 -- Verify that all API responses contain Content-Type headers with the correct content type
Verification method: Check API response headers. Status guidance: If API endpoints return incorrect Content-Type headers, this fails.
V13.2.1 -- Verify that enabled RESTful HTTP methods are a valid choice for the user or action
Verification method: Test API endpoints with unexpected HTTP methods (PUT, DELETE, PATCH on read-only endpoints). Status guidance: If the API accepts methods beyond what's documented, this indicates insufficient method restriction.
V13.2.3 -- Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery
Verification method: Check for CSRF tokens or SameSite cookie attributes on state-changing API endpoints. Status guidance: If state-changing API requests succeed without CSRF protection, this fails.
V13.4.1 -- Verify that each HTTP response contains a Content-Type header field specifying a safe character set
Verification method: Check response headers for charset specification. Status guidance: Responses without charset specification may be vulnerable to character encoding attacks.
How to use this reference
- For each requirement, determine Pass or Fail status.
- Map your exploitation findings. Your confirmed vulnerabilities from Units 5 and 6 are direct evidence of specific ASVS failures. The SQL injection you found proves V5.3.4 fails. The BOLA you found may relate to V13.2.1 or V5.2.4. Make the connection explicit.
- Items that pass are also important -- they demonstrate what the application does correctly. Include them in the compliance documentation.
- Select the appropriate verification level. L1 is correct for Dimitar's application (internet-facing e-commerce). L2 and L3 would apply to applications handling sensitive data at higher volumes or in regulated industries.