API10:2019 - Insufficient Logging & Monitoring
Tags: security, hacking, api, owasp
Published: 2022-03-19 21:47:50

Hi, everyone! Hope you are having an amazing day 🤗

Today, I'm here to write about the last topic of our OWASP API Security TOP 10 series, which is also the last item in their list. Although it seems, by its name, to have a pretty straightforward concept just like [API6:2019](https://dev.to/therealbrenu/api62019-mass-assignment-3b76) has, API10:2019 may not be exactly the case!

## :national_park: Logging and Monitoring

First of all, I would like to differentiate these two concepts, because when I read API10:2019's name for the first time I thought it was a little bit redundant. Aren't logging and monitoring just the same thing? 🤔

Well, not exactly. Although logging and monitoring have a strong relationship between each other, they also have two different meanings.

### 📈 Logging

Personally, I like the definition that can be found on this [really nice lesson from hacksplaining](https://www.hacksplaining.com/exercises/logging-and-monitoring):

`Logging refers to having an application write a record of each event that occurs (...). These “log files” can be read by administrators to analyse what the application was doing at a given point in time.`

These event records may vary from simple ones, such as endpoints being called, to also things like alerts, exceptions being triggered, etc. They may also have different "levels" so it gets easier to look for more specific events, but they generally have a pretty similar format, regardless of their level.

### 📈 Monitoring

Monitoring may have different purposes, depending on the context of the application, but this whole series was about securing APIs, and when it comes to this specific context, I would describe monitoring as being a step after logging, where interesting activities (suspicious ones) can be separated and flagged as potential attacks.

These flagged activities, depending on the possible criticality, may also trigger alerts to be sent through email, SMS, Telegram, etc...so that the responsible people get aware instantly.

## :flushed: When it becomes a threat 

So how can things go wrong? Well, there are some different cases. In some of them, not having enough logging and monitoring is the problem, and in some other cases, a logging or monitoring functionality may also be the exact root cause of a security issue.

Let's say you have a web application in which there is an administration feature that let's you see all of the application logs being displayed like this:

![Screen with log messages being displayed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3uxr56d67xbwf0ruoufl.png)

Given this cool logging feature, API10:2019 could still happen in scenarios such as:

- There is no monitoring, so the administrator has to be watching logs 24/7 😓
- These logs include sensitive data, such as users' credentials when they try to authenticate 😨
- The endpoint that gives these logs to the UI is not restricted to admin-only users (just like [API5:2019](https://dev.to/therealbrenu/api52019-broken-function-level-authorization-1jl0)) 🤡
- The API doesn't sanitize the content of these logs before retrieving them, making them a possible vector of injection attacks (from XSS to even OS Command Injection) 😭

More cases and prevention methods can be found on the [OWASP API Security Top 10 official repository](https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xaa-insufficient-logging-monitoring.md)

## :hugs: Thank you! 

It was a really nice experience to write this series, and I learned a lot while writing each blog, especially after realizing that each vulnerability can be connect to others on the list. I enjoyed this process of sharing what I'm learning, and in the future you guys may see a different series, but for now I am going to focus more on college stuff and make just punctual blogs 😋

And to whoever read this weird series until the end, thank you for taking your time and thank you for your patience 🤗