The login failed. The password ended up in the logs.
In this controlled demo, the app logs the whole login request to help with debugging, and that includes a fake password. Anyone who can read the logs can read it.
Demo built and tested 1 Oct 2026 · Published 1 Oct 2026 · Last reviewed 1 Oct 2026 · By Ctrl+Z Therapy (how we test)
Can passwords end up in my app's logs?
Yes, if the app logs whole requests. A login request carries the password, so logging the full request writes the password into your logs in plain text. In our controlled demo, a failed login logged a fake password. Logs are data too: anyone who can read them can read that. The fix: log only what you need, like the event and a request ID, and never passwords, tokens or API keys.
How to tell if your app has this
No code needed.
- Log in to your own app with a wrong test password you'll recognise, then search your logs for it: your host's function logs, your server logs and your error tracker.
- Search the same logs for the words password, token and key.
- Ask your AI tool: "What do we write to the logs when a login fails? Do we ever log request bodies, headers or tokens?"
Before and after
A failed login wrote the password to the log in plain text.
The event and a request ID are logged. The password isn't.
Why AI-built apps end up with this
When something breaks, the quickest debugging step is to log everything, and AI tools often add exactly that: the whole request or the whole error object. It helps fix the bug, then stays in the code. Nothing on screen shows it, so it ships.
How do I fix it? Paste this into your AI tool
My app writes whole requests to the logs, so passwords end up there. Find every place we log request bodies, headers, form data or whole error objects: on the server, in serverless or edge functions, in error trackers and in the browser console. Log only what we need to debug, like the event name, a request ID, the user ID and the error message. Never log passwords, tokens, API keys, session cookies or card numbers, and add a filter that removes those fields if they slip in. Then search our existing logs for passwords or keys, tell me how to delete those entries, and list any keys or tokens we should rotate.Works with Lovable, Bolt, Cursor, Replit and similar tools. Then run the check-up below on your own app.
How we checked the fix
| Same request | Before | After |
|---|---|---|
| Failed login with a fake password | Whole request logged, password included | Event, request ID and username only |
Results from our demo test, run against the same demo before and after the fix.
Common mistakes when fixing this
- Removing the logging line doesn't remove the passwords already in your logs. Delete those entries and rotate any keys or tokens that were logged.
- Error trackers and the browser console count too. Check what gets sent along with each error.
Questions people ask
Who can read my logs?
Anyone with access to your hosting dashboard, error tracker or log service, and any tool connected to them. That is often more people and services than can see your database.
I found passwords in my logs. What now?
Remove the logging first, then delete or redact the affected entries and rotate any keys or tokens that were logged. If real user passwords were exposed, consider asking those users to change them.
What should I log instead?
The event (for example login_failed), a request ID, the time and, if you need it, the user ID. That is enough to trace a problem without storing secrets.
For developers: the cause and the fix in code
− log(json.dumps(request_body)) + log({"event": "login_failed", + "request_id": request_id, + "username": body["username"]})
Simplified. Your stack will look different; the principle is the same.