Skip to content
Kodesec × Integrated-Systems.ai
KODESEC
Book a call

A09 · OWASP Top 10 · 3 min

Security logging and alerting failures. If a break-in happened tonight, would you know?

Attackers rarely strike once and leave. This is about whether your site records what happens, and whether anyone is told when something looks wrong.

I run a

In 10 seconds

Attacks that happen without anyone noticing.

What it is

Logs are your website's security-camera footage, and alerts are the alarm. A failure is when important events aren't recorded, the records can be erased, or nobody is told or looks.

Why you care

It doesn't cause break-ins. It lets them run for months. The longer an attacker stays unseen, the more of your names, addresses, phone numbers and purchase history they can reach, and the harder it is to say what was taken.

What to do

Ask four things: what do we record, who is alerted, who responds, and when did we last test it?

For your business

What's at stake for you.

I run a

Who is affected

Your customers, and anyone who trusts you with their details.

What could leak

Names, addresses, phone numbers and purchase history.

Ask this first

“What security events do we record: sign-ins, failures, admin changes, exports?”

Where it hides

Pick a part of your watch system.

A camera is useless if it's off, unwatched, or the tape can be erased. Each of these can fail on its own.

logs > sign-ins
What's here
Records of who logged in, from where, and what they did, including failures.
What goes wrong
Failed and successful logins aren't recorded, or are kept for only a few days, so a month-long takeover leaves no trail.
Ask your team
Do we record every sign-in, failed attempt and admin action, and how long do we keep those records?
Developers call it
Insufficient audit logging, short log retention

What it costs

Time is what the attacker gains.

Slow discovery

Industry studies, such as IBM's yearly Cost of a Data Breach report, have put the average time to find and contain a breach at several months.

Bigger damage

The longer they stay, the more they take, and the more you have to assume was taken.

No answers

Customers, regulators and insurers ask what was taken. Without logs you can't say, so you may have to assume the worst.

Told by others

Many breaches are first spotted by someone outside the company, not by its own systems.

For an online shop: after an incident you'd need to say whose names, addresses, phone numbers and purchase history were accessed. Without logs, you can't.

Does this apply to you?

Tick what's true. Get your questions.

First

So the questions fit you

What kind of business do you run?

Real cases

The camera was there. The answer wasn't.

The alarm rang, 2013

The alerts worked. Nobody answered them.

What it cost
Target's chief executive resigned in 2014.
The lesson
The alarm worked. Nobody was set up to answer it. Alerts only help if someone owns the response.
Read the full story and sources

In late 2013 attackers installed card-stealing software on Target's payment systems. A security tool from FireEye spotted the malware and raised alerts, which were passed on to Target's security staff in the US. The alerts weren't acted on, and the attackers kept going, taking about 40 million payment card numbers and personal details of up to 70 million customers.

Target's chief executive resigned in 2014. The company later reached an $18.5 million settlement with US states and reported breach-related costs of around $200 million.

Sources: US Senate Commerce Committee report (2014), Bloomberg Businessweek, Target filings.

Your part

Three decisions that are yours.

  1. 01Decide what must be recordedAt minimum: sign-ins and failures, admin changes, permission changes and large data exports. Keep the records long enough to investigate, for example a year.
  2. 02Name who watches and who actsSomeone owns the alerts, including nights, weekends and holidays, whether in-house or an outside service.
  3. 03Rehearse itWrite an incident plan and practise it once a year, so the first time isn't the real time.
For your developer: the technical layer
  • Log authentication events, access-control failures, input-validation failures, admin actions and exports, each with timestamp, user, source and outcome.
  • Use structured logs with correlation IDs and synchronised clocks, so events from different systems can be put in order.
  • Ship logs in near real time to a central, access-controlled, append-only store that is separate from the application host.
  • Never log passwords, tokens, full card numbers or other secrets, and encode logged input to prevent log injection.
  • Keep alerts few and high-signal: bursts of failed logins, new admin accounts, mass exports, unusual locations. Define severity and escalation to avoid alert fatigue.
  • Align retention with legal needs and investigation time, and regularly test that alerts really reach a person.
  • Consider canary tokens and decoy accounts for high-confidence alerts, and run tabletop exercises.

Remember

Three things to keep.

  • Logs and alerts don't stop attackers. They shorten how long attackers stay.
  • An alarm nobody answers is the same as no alarm. Name an owner.
  • Record enough to answer: what happened, when, and whose data.

What OWASP says

The essentials, slide by slide.

A09 · owasp top 10 · 01/04

OWASP Top 10 · A09

security logging and alerting failures

Source: OWASP Top 10:2025 (CC BY 3.0) ↗

OWASP is a non-profit that publishes the industry's standard list of web risks. Safety measures adapted from the OWASP Top 10:2025 (CC BY 3.0). The people and businesses in the examples are made up.