The OWASP logging vocabulary gives security events consistent names built from a category prefix and an action, such as authn for authentication events. When every service uses the same names, one alert rule can cover all of them instead of one rule per application.
What the vocabulary is
The cheat sheet standardizes names for security relevant events so teams can monitor and alert consistently. Its premise is that if developers log events using shared terms, monitoring and alerting improve by keying on those terms.
The naming pattern
Names follow category, action and optional fields after a colon. Categories listed on the page include authn for authentication, authz for authorization, session, input_validation, malicious, sensitive, user and sys, among others.
Each event on the page has a description, a severity of INFO, WARN or CRITICAL, and an example log record. For instance, failed logins are rated WARN, while impossible travel and token reuse are rated CRITICAL.
A record has fields such as datetime in ISO 8601 with a UTC offset, appid, event, level, description and optional request metadata like source IP, user agent and request URI.
Using it in your own code
You do not have to adopt every event. A practical approach:
- Pick ten events you care about: login success and failure, password change, role change, access denied, session expired, input rejected, admin action, sensitive data export.
- Name them with the category prefix pattern.
- Put the names in a shared constants file so typos cannot create new variants.
- Write alert rules against the prefixes. For example, count authn failures per source per five minutes.
Why consistent names pay off
Imagine ten services. If each writes its own text for a failed login, you need ten parsers. With one event name, a single query finds all failures, and a single rule catches a credential stuffing attempt across every service.
Watch the payload
Some entries on the page advise logging a rule ID or category instead of the full payload, for example when recording a detected injection attempt. This avoids storing attacker content and keeps log injection risk down. The page also reminds you that secrets, keys, certificates and source code should never be logged.
Severity is a suggestion
The levels on the page are a starting point. A failed login is routine on its own and meaningful as a burst. Alert on the pattern, not each line.
Map to your risk
OWASP's main logging guidance also calls for logging proportionate to risk and warns against alarm fog. Start with events that signal abuse of your own highest value actions, and add more as you learn what attackers actually try.
Quick check
Do I need to copy the exact names?
No, but copying them saves design time and helps if you share dashboards or rules across teams.
Should every event be an alert?
No. Log broadly, alert narrowly, and tune thresholds on counts and rates.
Sources
Last reviewed: 19 October 2026.
