ASVS 5.0 V16.3.3 requires the application to log the security events defined in its documentation, and also attempts to bypass security controls such as input validation, business logic and anti automation. It is Level 2. When a control blocks something, record that it did, with who and what.
Why it matters
Attackers rarely succeed on the first try. They probe. A rejected input, an impossible state transition or a spike of requests to a rate limited endpoint is early warning. If controls reject silently, you lose the chance to react before a probe finds a gap.
How to implement it
Define the event list in your security documentation, then emit an event at each control's rejection path.
- Input validation failure on a field that a normal client would never send wrong, such as a tampered hidden value or an enum outside its range.
- Business logic violation, such as an order total that does not match line items, or skipping a workflow step.
- Anti automation trigger: rate limit hit, bot challenge failed, repeated lockouts.
function rejectInput(req, field, reason) {
logger.warn({
event: "security.input_rejected",
user_id: req.user?.id ?? null,
ip: req.ip,
route: req.route.path,
field, // the field name, not its value
reason, // out_of_range, wrong_type, tampered
request_id: req.id,
});
}
Keep values out of the log or truncate and encode them to avoid log injection and sensitive data exposure. Route these events to alerting with thresholds, for example more than 20 in five minutes per source.
How to test it
Perform one bypass attempt for each control in the documentation: tamper a price, replay a step out of order, exceed a rate limit, send a malformed value. Confirm each produces a log entry with the event name, actor and route. Check the log does not echo a hostile payload raw.
Common mistakes
- Logging only successful security events.
- Treating every validation error as noise and logging none.
- Logging raw attacker input, which enables log forging.
- No documented event list, so nobody knows what coverage is expected.
Quick check
Should every typo in a form be logged as an attack?
No. Focus on events a normal client could not produce, and on repeated failures from one source.
