Masking sensitive data in Log4J 2 — The simplest way possible

Alexandre Saudate
2 min readMay 27, 2021
Sensitive data must be at least masked in every software, according to GDPR, PCI-DSS, and several other laws and/or regulations concerning data protection

Recently, I came across a problem that I believe happened (or will happen) in the life of every developer: masking sensitive data in logs.

Although this is a very common concern, it surprised me how long it took to figure out a solution for the problem.

I’ve read several blogs , StackOverflow, etc., searching for means on how to do it. I’ve read about RewritePolicy, found some plugins already developed, etc. But none of these solutions actually solved my problem.

It turns out Log4J has a severe problem: it completely lacks proper documentation for configuration using properties files. And its community follows along.

So I couldn’t use the engine’s approach to do what I needed because all I found was how to do it using XML files. And the system I am working is already using a .properties file.

But in the end, the solution I ended up coming with (again, after a lot of research) was developing a custom pattern converter. This converter actually receives all the message log in a StringBuilder, which allows me to edit it as I wish.

So I crafted a class like this one:

As you can see, the class is located in the package org.example . So the next step would be to properly configure and use it.

So for Log4J 2 to use this class I must use a property called packages , which scans the packages provided for classes annotated with @Plugin . Once it does, setting up the pattern is fairly simple. So my properties file ended up like this one:

Note that I had to place the expression %ex{full} before %hideEmails . Otherwise, Log4J inserts this expression by default after the whole pattern, thus causing any exceptions (which might contain sensitive data as well) to be print without passing by the filter.

And that’s it! Now, every word on the log (whether it’s in the message or in exception’s body) will be covered by this filter and thus will be protected against sensitive data.

Of course, the solution is also extensible to allow you to do some other filtering, like removing credit card’s data, customer’s names, anything. As you have full access to the data, this should not be a concern.

I must say a very special thank you to folks behind https://facingissuesonit.com/2018/06/08/log4j2-how-to-mask-logs-personal-confidential-spi-information . My solution is heavily based on theirs.

--

--

Alexandre Saudate

Java / Kotlin developer & Architect. Love Spring Boot, Reactive Programming, DevOps, etc.