Missing username in log files when using API Token

[NoaFayn]

Slack us first!
Done!

Be informative
Regarding the logs of the uwsgi container, it correctly shows the username of the user making the request on the web server, but doesn't for the API calls.

When using the web interface (to access web pages), the uwsgi container logs the following:

uwsgi-1  | [pid: 41|app: -|req: -/-] 172.18.0.1 (USERNAME) {64 vars in 1258 bytes} [XXX] GET /alerts/count => generated 15 bytes in 57 msecs (HTTP/1.1 200) 7 headers in 212 bytes (1 switches on core 1)

However, when making a request to the API using an API token, the log is as follow:

uwsgi-1  | [pid: 41|app: -|req: -/-] 172.18.0.1 (-) {44 vars in 681 bytes} [XXX] GET /api/v2/findings/3473444/ => generated 2403 bytes in 311 msecs (HTTP/1.1 200) 8 headers in 261 bytes (1 switches on core 2)

Notice the dash instead of the username of the user who generated the API token and performed the request.

This appears only when using the Token provided by the /api/key-v2 page.
If the user uses the swagger UI to make the API request, then the username correctly appears.

After discussion on Slack:

So issue is connected to AuthN method, not to url.

This may need custom middleware to get loggeed: https://stackoverflow.com/questions/26240832/django-and-middleware-which-uses-request-user-is-always-anonymous

Bug description
A clear and concise description of what the bug is. For errors include at least the exact error message you are seeing (including traceback).

Steps to reproduce
Steps to reproduce the behavior:

1. Go to /api/key-v2 page using web interface
2. Copy the given python code example (using Authorization Token in the headers)
3. Execute the script
4. Look at the uwsgi container logs and notice that the username doesn't appear in the logged request

Expected behavior
I expect the username to appear in the logs.

The logs are used for traceability and having no indication of the user that performed a request is a flaw that prevent forensic analysis or event simply traceability.

Deployment method

• Docker Compose
• Kubernetes
• GoDojo

Environment information

• Operating System: Debian 12
• Docker Compose: v2.39.4
• DefectDojo version: tested on v2.51.3 and v2.52.1

Logs

uwsgi-1  | [pid: 41|app: -|req: -/-] 172.18.0.1 (USERNAME) {64 vars in 1258 bytes} [XXX] GET /alerts/count => generated 15 bytes in 57 msecs (HTTP/1.1 200) 7 headers in 212 bytes (1 switches on core 1)
uwsgi-1  | [pid: 41|app: -|req: -/-] 172.18.0.1 (-) {44 vars in 681 bytes} [XXX] GET /api/v2/findings/3473444/ => generated 2403 bytes in 311 msecs (HTTP/1.1 200) 8 headers in 261 bytes (1 switches on core 2)

Sample scan files
N/A

Screenshots
N/A

Additional context (optional)
N/A

[valentijnscholten]

@NoaFayn I'm not sure we should consider this a bug or enhancement. In EU we usually get the reverse of this request which is to remove any usernames or other possible PII from logs. Could you let us know your use case or requirements? Do you need these logs because the audit log of Defect Dojo is not enough?

I am not saying we won't implement it, but for now I think we'll mark this is help_wanted and accept a community contribution on it.

[NoaFayn]

@valentijnscholten Thank you for the response! Let me explain my position:

To me, this is not an enhancement, as the username is already logged correctly for a request made through the UI (and even the API using swagger), but not when using an API token. So from my point of view, the logs should have this information and in the case that I've described, it is missing, so I would qualify it as a bug (in the sense of a feature that is not behaving as expected). But if you tell me that the missing username from the logs for the API token only is by design, then I'm fine to call this an enhancement.

Regardless of the qualification of this issue, I disagree with you comment about EU and personal data in logs for several reasons.
First, the username is something that can be set to anything, and do not necessarily represent personal data. Next, even if it is considered personal data, I don't see a problem to log this information. GDPR (if this is what you worry about) doesn't prohibit logging personal data. It only require that it is handled properly, and that users are informed and consent to it. (This is an over-simplification, but the point still stand; GDPR doesn't explicitly prohibit logging personal data.)
Finally, I would still expect DefectDojo to give me the ability to choose whether this information appears or not in the logs, and let me decide if I want it or not.

As for my use-case, the most common one is when a user is experiencing an error with DefectDojo, I want to be able to retrace what this user did to help me understand what the error was, when it occurred, what API triggered the error, etc. in the hopes of reproducing it.
As of today, since most of my users use the API within their CI pipelines, the logs are "unusable" (i.e. I can't track separate requests by user).

Another point that I raise is that to comply with some standards (for instance ISO 27001), we do need traceability and accountability for the operations performed in security tools.

You mentioned audit logs in DefectDojo, they are useful for existing objects in the instance, but less so for deleted ones. Or maybe I don't know how to use them correctly? If you have some tips I'm all ears! But for the use-case of "given a user, what were they actions on the system", I'm having trouble using audit logs.

If you could point me in the right direction (where are logs formatted for instance?), maybe I can have a look.