Audit Logs in Web Apps: What to Record and Why

What an audit log is for

Most servers already write logs: the web server records requests and the database records errors. The OWASP Logging Cheat Sheet says this is not enough: "often custom application event logging is missing, disabled or poorly configured." Only the app knows who the user is, what role they hold and which record they touched. OWASP puts it this way: "the primary event data source is the application code itself."

OWASP lists audit trails among the security uses of application logs, with examples such as "data addition, modification and deletion, data exports". It also notes that audit and transaction trails "are usually collected for different purposes than security event logging, and this often means they should be kept separate." In practice a web app often has two streams: a business audit trail (who changed which invoice, who invited which user) and a security event log (failed logins, refused access, input that should never arrive). They can share tooling, but they answer different questions and may have different readers.

Missing logs are a known risk. The OWASP Top 10:2025 lists Security Logging and Alerting Failures as A09, and opens with: "Without logging and monitoring, attacks and breaches cannot be detected".

Which events to record

OWASP warns against copying a checklist blindly, because it "can lead to unnecessary "alarm fog" that means real problems go undetected." The level of logging should be set at the requirements and design stage and be "proportionate to the information security risks." With that caveat, the cheat sheet lists events to log where possible. For a typical business web app the most useful are:

• Sign-in events: "Authentication successes and failures", including lockouts and password changes.
• Refused access: "Authorization (access control) failures", such as a user trying to open another customer's record.
• User administration: adding or deleting users and "changes to privileges".
• Administrator activity: OWASP lists "access by application administrators including all actions by those users", plus use of shared or "break-glass" accounts.
• Sensitive data and exports: access to sensitive data, and "Data import and export including screen-based reports".
• Consents: terms accepted, marketing permissions and "personal data usage consent".
• Odd business behaviour: steps done out of order, or "Attempts to exceed limitations for particular actions".
• Configuration changes and application errors.

Who may do what in the first place is covered in our guide to roles and permissions in a web app. The audit log is the record of those rules being used and tested.

OWASP's companion Logging Vocabulary Cheat Sheet suggests fixed event names, so every part of the app writes the same event the same way. Examples include authn_login_fail, authz_fail ("An attempt was made to access a resource which was unauthorized"), authz_change, user_created and sensitive_read. For administrators it says: "All activity by privileged users such as admin should be recorded." Consistent names make searching and alerting much simpler than free-text messages.

What each entry needs

OWASP's rule is short: "The application logs must record "when, where, who and what" for each event." In plain terms:

• When: the date and time in an international format. The vocabulary cheat sheet asks for ISO 8601 "WITH UTC offset". Server clocks should be synchronised.
• Where: the app and version, the server, and the page or API endpoint with its HTTP method.
• Who: the user ID if known, and the source address. In a multi-customer app, also record the customer account.
• What: the event type, its severity and a description.

OWASP also suggests recording the action, the object it was aimed at, the result ("Success, Fail, Defer") and the reason. An "Interaction identifier" that links all events from one request saves a lot of guesswork later. For a business audit trail, it often helps to store the old and new value of a changed field, as long as that value is not on the exclusion list below.

What to keep out of the log

A log that stores passwords or card numbers becomes a target in its own right. OWASP says certain data "should usually not be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed, or encrypted". Its list includes:

• authentication passwords, access tokens and session identification values;
• encryption keys and database connection strings;
• bank account or payment card holder data;
• sensitive personal data such as health information or government identifiers;
• information a user has opted out of or not consented to.

OWASP also says: "Never log data unless it is legally sanctioned." The vocabulary cheat sheet adds that even an IP address "may be considered personally identifiable information when combined with other data". The GDPR principle of data minimisation in Article 5 asks that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed". Logs count. Record what you need to answer the questions above, and no more.

Protecting the log itself

A log is only useful if people trust it. OWASP says logs must be protected from "tampering in transit, and unauthorized access, modification and deletion once stored." Its practical steps:

• "Build in tamper detection so you know if a record has been modified or deleted".
• "All access to the logs must be recorded and monitored".
• Restrict and regularly review who can read the logs.
• Keep logs out of web-accessible folders, and when writing to a database use "a separate database account that is only used for writing log data".
• Send logs over a secure protocol when they cross untrusted networks.

The Top 10 entry asks for "an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar", and lists "Logs are only stored locally, and not properly backedup" as a failure. Logs can also be attacked through what users type. OWASP describes log injection, where an attacker who can insert line breaks can "cause an additional log entry that looks like it came from a completely different user". Its advice is to use structured formats such as JSON, encode values, and limit the size of user input written to the log.

These controls sit alongside the wider basics in our small business website security guide.

Activity logs your customers can see

Many business apps show account owners an activity log: who signed in, who changed a setting, who exported a report. That is useful, but it is also a place where data can leak. OWASP's Top 10 entry warns about "making logging and alerting events visible to a user or an attacker". If you build a customer-facing log, it should go through the same permission checks as the rest of the app. In a multi-customer app that means every log query is limited to the signed-in customer's own records, as described in our multi-tenant basics guide. Internal security events, such as stack traces or detection rules, usually stay in the internal log.

How long to keep logs

There is no single correct retention period, and this guide does not suggest one. OWASP says log data "must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time", and that "Legal, regulatory and contractual obligations may impact on these periods." Under GDPR Article 5, personal data should be kept "for no longer than is necessary for the purposes for which the personal data are processed", and the controller must "be able to demonstrate compliance". Article 32 asks for security measures that include "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services". Your retention period is a decision for you and your legal or compliance advisers, written down and then built into the app.

For the wider process, NIST's SP 800-92, Guide to Computer Security Log Management was published in September 2006 and is the final version on NIST's publications site. A Rev. 1 draft, the Cybersecurity Log Management Planning Guide, was published on 11 October 2023 as an initial public draft; its comment period closed on 29 November 2023. NIST defines log management there as "the process for generating, transmitting, storing, accessing, and disposing of log data."

Alerts and tests

A log nobody reads only helps after the damage is done. OWASP asks teams to "Enable alerting and signal the responsible teams about more serious events immediately", and to detect "whether logging has stopped". The Top 10 entry also flags the opposite problem: too many false alerts, so the important ones are "recognized too late or not at all". Start with a few alerts that matter, such as repeated failed sign-ins on one account, a burst of refused access, or a new administrator account.

Logging also needs testing. OWASP says logging "must be included in code review, application testing and security verification processes". It asks teams to check that events are classified consistently, that logging cannot fill the disk, and that a logging failure does not stop the app or leak information. The same verification list includes: "Verify access controls on the event log data".

What to put in the brief

Audit logging is far cheaper to design in than to add later. Before the build, agree with your developer:

• the list of events to record, with fixed event names;
• the fields in each entry, including user, customer account, object and result;
• which data never goes into a log, and how other personal data is masked;
• where logs are stored, who can read them, and how tampering is detected;
• whether customers get their own activity log, and what it shows;
• the retention period your business has decided on, and how old logs are deleted;
• the first alerts, who receives them, and how logging is tested.

FAQ

What is the difference between an audit log and a security log?

An audit trail records business actions such as who changed, deleted or exported which records. A security event log records things like failed sign-ins and refused access. OWASP notes that audit and transaction trails are usually collected for different purposes than security event logging, and often should be kept separate.

Should passwords or tokens ever appear in logs?

No. OWASP lists authentication passwords, access tokens, session identifiers, encryption keys and payment card data among the items that should be removed, masked, sanitized, hashed or encrypted rather than written to logs directly.

How long should we keep audit logs?

There is no single answer. OWASP says logs must not be destroyed before the required retention period and must not be kept beyond it, and that legal, regulatory and contractual obligations affect those periods. Under GDPR, personal data in logs should not be kept longer than necessary for its purpose. Decide the period with your advisers and write it down.

Can customers see their own activity log?

They can, if the app is built for it. The log must pass the same permission checks as the rest of the app, so each customer sees only their own account's events. OWASP warns against making logging events visible to a user or an attacker.

How do we stop someone editing the log?

OWASP recommends tamper detection, restricted and reviewed read access, recording all access to the logs, and storing or copying log data to read-only media as soon as possible. The OWASP Top 10 suggests integrity controls such as append-only database tables.

Planning a web app that needs a reliable audit trail? See our web app development service and all our services, or email [email protected].