Table of contents
- The myth of logging as an absolute good
- When logs become an attack surface
- Logs containing tokens and sessions: a concrete risk
- PII in logs and compliance implications
- Post-breach attacks and poorly protected SIEMs
- The real cost of unnecessary retention
- Logging and architecture: a design issue
- Toward conscious logging
In the world of cyber security, logging has always been considered an absolute good. More logs mean more visibility, more investigative capability, more control. Or at least, that’s the story we’ve been telling ourselves for years. In reality, the indiscriminate collection of logs is becoming one of the most underestimated problems in modern security.
This article takes an in-depth look at excessive logging as a new attack surface, highlighting real implications for security, compliance, and system architecture. This is not theory, but concrete incidents, hidden costs, and risks that often emerge only after a breach.
The myth of logging as an absolute good
For years, logging has been treated as a form of insurance. If something goes wrong, “at least we have the logs.” This mindset was born in an era when systems were simpler, data less sensitive, and information protection regulations far less strict. Today, the context has radically changed, but the conditioned reflex remains the same: log everything, always and no matter what.
In many enterprise environments, especially cloud-native ones, logging is enabled almost automatically. Application frameworks, third-party libraries, middleware, and infrastructure services generate massive amounts of data without anyone really asking the fundamental question: why are we logging this information? The result is uncontrolled data growth, often unread, but stored for months or years.
This approach stems from an understandable fear: losing useful information during an incident. But paradoxically, excessive logging ends up producing the opposite effect. Too much data makes it harder to identify relevant signals, increases operational noise, and introduces new risks that are often ignored until it’s too late.
When logs become an attack surface
Every piece of stored data is, by definition, a potential target. Logs are no exception—quite the opposite. They often contain extremely sensitive information precisely because they are designed to “tell everything” about what is happening in a system. Authentication tokens, session IDs, API keys, email addresses, phone numbers, document references, application error details: everything can end up in logs if there is no clear filtering policy.
In many cases, logs are not protected at the same level as primary databases. They are sent to SIEM systems, observability platforms, or centralized storage with weaker access controls. This creates a dangerous situation: an attacker who manages to compromise the logging system can gain a complete view of the infrastructure, often more detailed than what administrators themselves have.
The problem is not just theoretical. In several post-breach incidents, attackers have exploited logs as a primary source of information to move laterally, impersonate legitimate users, or reconstruct authentication flows. In these scenarios, excessive logging was not an ally of defense, but a multiplier of attack impact.
Logs containing tokens and sessions: a concrete risk
One of the most common mistakes is recording access tokens or session identifiers in logs. This often happens during development, when logs are used for debugging, but remains active in production.
Example
Full logging of HTTP headers, which may contain JWT tokens or session cookies.
From an attacker’s perspective, this data is pure gold. A valid token can allow direct access to protected services without the need to brute-force credentials. If logs are accessible, even temporarily, the risk of abuse is extremely high. In cloud environments, where logs are often aggregated in centralized systems, a single misconfiguration can expose thousands of tokens.
The problem is compounded by the fact that many logging systems are not designed for secret management. They do not provide automatic rotation, masking, or invalidation of sensitive data. Once a log is written, the information stays there, possibly replicated across multiple backup and retention systems, increasing the exposure window.
PII in logs and compliance implications
Beyond pure security aspects, excessive logging has a direct impact on regulatory compliance. Personal data (PII) often ends up in logs accidentally: names, email addresses, IP addresses attributable to individuals, user identifiers. In many cases, no one realizes that this data has been collected, because logs are not treated as a real datastore.
From the perspective of GDPR and other data protection regulations, this is a serious issue. Every piece of personal data must have a legal basis, a clear purpose, and a defined retention period. Logs, however, are often kept “for security reasons,” without real justification and without a deletion plan. This exposes organizations to fines and disputes, especially in the event of a data breach.
A frequently overlooked aspect is the right to erasure. If a user exercises the right to be forgotten, how are their data handled within logs? In most cases, they simply aren’t. This creates a dangerous misalignment between declared policies and the technical reality of systems.
Post-breach attacks and poorly protected SIEMs
Another widespread myth is that a SIEM is automatically a secure environment. In reality, many Security Information and Event Management platforms are accessible from broad internal networks, integrated with numerous systems, and managed by different teams. This makes them an attractive target after an initial compromise.
In several incidents, attackers have used the SIEM as a reconnaissance tool. By analyzing logs, they were able to understand which systems exist, which users are active, which errors occur, and which access attempts are recorded. In practice, the system designed to monitor security becomes a detailed map of the infrastructure.
The problem is exacerbated when the SIEM retains highly detailed logs for long periods. The more data is available, the easier it is for an attacker to reconstruct past events and identify patterns useful for future attacks. This completely overturns the traditional narrative of logging as a defensive tool.
The real cost of unnecessary retention
In addition to security and compliance risks, excessive logging carries an often underestimated economic cost. Storage, indexing, SIEM licenses based on data volume, compute resources for analysis—all of this has a direct impact on IT budgets. In many cases, a significant percentage of security costs is tied to managing logs that are never actually consulted.
But the cost is not only economic. There is also an operational cost. SOC teams find themselves overwhelmed by alerts and information, with increasing difficulty distinguishing truly important signals. This phenomenon, known as alert fatigue, reduces overall defensive effectiveness and increases the risk that a real incident goes unnoticed.
In this sense, excessive logging is not just inefficient—it is counterproductive. More data does not automatically mean more security. Often, it simply means more noise.
Logging and architecture: a design issue
Addressing excessive logging requires a shift in architectural perspective. Logging should not be an automatic byproduct of the system, but a component designed with the same care as other critical aspects. This means clearly defining what to log, at what level of detail, and for how long.
A mature approach involves classifying logs based on their value and sensitivity. Not all logs are equally important. Some are essential for security, others only for temporary debugging. Treating them the same way is a design mistake. It is necessary to introduce logging levels, masking policies, and differentiated retention mechanisms.
From an architectural standpoint, it is also important to separate operational log streams from security logs. Mixing everything into a single system increases risk and complexity. More granular design allows for stricter access controls and reduced exposure of sensitive data.
Toward conscious logging
The true value of logging emerges when it is used consciously. This means accepting that not everything must be recorded and that losing some details is an acceptable trade-off compared to the risks introduced. Effective logging is selective, targeted, and aligned with security and compliance objectives.
In practice, this approach requires collaboration between developers, architects, and security teams. Logs should not be decided only during development or only by the SOC. They must be the result of a shared strategy, based on a real risk assessment. Only then can logging return to being a defensive tool rather than a silent vulnerability.
Conclusion
The invisible problem of logs is one of the paradoxes of modern cyber security. What we have long considered an absolute good is becoming, if not properly managed, a significant risk. Excessive logging expands the attack surface, complicates compliance, and introduces hidden costs that often emerge only after an incident.
Rethinking logging does not mean giving up visibility, but making it sustainable and secure. In a context where every piece of data can be a double-edged sword, true maturity lies in knowing what not to log.
Questions and answers
- What is excessive logging?
It is the practice of recording large amounts of data without a real evaluation of its value or associated risks. - Why can logging become a security risk?
Because logs may contain sensitive information useful to an attacker in case of compromise. - Can logs contain personal data?
Yes, they often include PII such as emails, IP addresses, and user identifiers. - What is the link between logging and GDPR?
Logs are subject to the same personal data protection rules required by GDPR. - Is a SIEM always secure?
No, if misconfigured it can become a prime target for post-breach attacks. - Why is log retention so expensive?
Costs include storage, licenses, analysis resources, and operational management. - Is it better to log less?
It is better to log selectively and consciously, not simply less. - How can tokens in logs be avoided?
By implementing masking, filtering, and application-level controls. - Who should decide what to log?
A shared decision between development, security, and architecture teams. - Does conscious logging reduce security?
No, if well designed it improves security by reducing noise and risk.
