DEV Community: Jaswanth. M

The Error Message That Hands Attackers a Map of Your Database

Jaswanth. M — Tue, 30 Jun 2026 01:12:54 +0000

A QA tip about why a "harmless" crash on a long number is bigger than it looks.

Here's a QA tip that has uncovered more serious problems than it has any right to.

Take any field that expects user input. A search box. A sort parameter. An ID field. Anywhere a value travels from the user into the database. Now feed it something it was never designed for: an unusually long number, far bigger than anything a normal user would ever type.

Most of the time the application handles it gracefully.
And sometimes, instead of a clean "invalid input," it throws a raw database error straight onto the screen.

That second outcome is the one worth paying attention to.
A crash is the symptom. The leak is the story.
When most people see an error on screen, they log it as "app breaks on long input" and move on. That is the bug. But it is not the interesting part.

A raw database error leaking to the user can reveal what is sitting underneath the application. Table names. Column names. The type of database running in the background. Sometimes a fragment of the actual query that failed.

Think about what that means for a second. A random oversized number, typed into an ordinary field, just convinced the application to describe its own internals to a complete stranger.
That is no longer a cosmetic bug. That is the system handing out a partial map of itself.

Why testers should care more than anyone
Here is the deeper signal. An application that spills a raw database error is almost always an application that is not properly validating and sanitising input before it reaches the database.

And that exact gap, unvalidated input flowing straight into database queries, is the root of some of the most serious and most exploited security problems on the internet.

So when a long number produces a database error, the number did not really "break" anything new. It exposed something that was already true: the layer between user input and the database needs a much closer look.
The crash was loud. The real problem was quiet, and it was there the whole time.

The defensive checklist
The good news is that fixing this is well understood work. None of it is exotic. It just has to actually be done, on every field, including the boring ones nobody thinks about.

Validate input before it reaches the database. Decide what each field should accept, and reject everything else.

Set sensible limits. A field that expects a small number should not silently try to hand a 16-digit value to the database.

Sanitise everything. Treat all user input as untrusted by default. Always.
Never let raw database errors reach the user. Catch them, log them privately where your team can see them, and show the user a clean, generic message instead.

That last point matters twice over. It protects your users from a confusing experience, and it stops your application from quietly narrating its own structure to anyone curious enough to type a weird value.
The mindset behind the tip

This is the part that outlives the specific trick.
Good QA is not only about asking "did it work?" It is about asking "what did breaking it reveal?" A crash is rarely just a crash. It is the system telling you something about what is happening beneath the surface, but only if you are paying attention to what comes back, not just whether it failed.

So the next time a field falls over on a strange input, do not stop at "throws an error." Ask what that error is exposing. Read it the way a curious outsider would. The bug is the symptom. What it reveals is the actual story, and usually the more important one.

If your application accepts user input, and every application does, it is worth checking how it behaves when someone hands it something it never expected. Far better that you are the one who finds it first.

Part of an ongoing series of honest notes from the testing trenches. If your "simple" input field has a story like this one, I would like to hear it.

1,000 Errors, One Google Sheet, and Five Hours I Will Never Get Back

Jaswanth. M — Thu, 25 Jun 2026 02:30:54 +0000

Every bug has an origin story. This one started, like most disasters do, with the words: "It works fine on my machine."

We were testing the data import feature for a lead generation company. You know the type of feature. There is a friendly little button that says Import, you hand it a spreadsheet full of contacts, and it politely loads them into the system. Simple. Boring. The kind of thing everyone assumes works because, well, why wouldn't it.

That assumption is exactly the kind of thing testers get paid to ruin.
The** happy path** is a beautiful liar

Here is the first rule of testing that nobody tells junior testers loudly enough: the happy path will lie to your face and smile while doing it.
We started the way the developers expected us to. We took a clean Microsoft Excel file, a nice tidy list of valid records, and clicked Import. It worked. Flawlessly. The data slid in like it was coming home. Everyone in the room relaxed a little.

upload(clean_excel) -> Import: Pass -> everyone goes to lunch

If we had stopped there, we would have written "Import: Pass" and gone home. The feature would have shipped. And a few days later, a real customer would have found what we were about to find, except they would have found it angry, in production, on a Monday.
So we did the thing testers are supposed to do. We stopped being nice.

Enter the villain: a Google Sheet

Real users do not live inside clean Excel files. Real users live in Google Sheets. They build their entire messy lives in Google Sheets and then expect every system on earth to accept that chaos without complaint.
So we exported the same data as a Google Sheet, fed it to the same innocent little Import button, and clicked.

The system did not just fail. It detonated.

upload(same_data_as_google_sheet) -> 1,000+ errors -> total meltdown

Over a thousand errors. One thousand. The screen filled up like the application was trying to set a world record for self destruction. It was almost impressive. If errors were applause, this feature just got a standing ovation.

Same data. Same button. Different source format. Total collapse.
Here is the part that matters: the developers were not wrong, exactly. They built the import for Excel, tested it with Excel, and it worked with Excel. But "it works with the file format we personally used" is not the same as "it works." Users do not read your mind about which spreadsheet brand you prefer. They just upload whatever they have and expect it to behave.

The sneakier monster nobody invited
We could have stopped at the Google Sheets explosion and called it a great day. But by now we had our troublemaker hats on, and troublemakers do not stop at the first fire.

So back to Excel we went, but this time we got mean about the data itself.

all_valid_rows -> imports fine
a_few_invalid_rows -> imports fine (skips the bad ones)
bulk_data_mostly_invalid -> breaks completely

All valid rows? Imported fine. A few invalid rows mixed in? Still imported fine. The system shrugged, skipped the bad ones, and moved on like a calm professional.

And then we did the thing real data actually looks like. We threw in a bulk file, hundreds of rows, mostly garbage, a few good records hiding in the mess. The kind of file a real sales team actually owns, because real sales data is 80 percent chaos and 20 percent gold.
It broke. Again.

Not "skipped a few rows" broke. Properly broke. The validation logic was perfectly happy handling a little bit of bad data, but pile on a mountain of invalid records with only a handful of valid ones, and the whole thing fell over like it had been waiting all day for an excuse.
This is the cruel little secret of import features everywhere. They are tested with small, clean, polite samples. They are used with enormous, filthy, real world files. The gap between those two is where customers lose their data and you lose their trust.

The five hours (a tragedy in one act)

I would love to tell you we found the root cause in ten minutes like geniuses. We did not.

We spent about five hours on this. Five hours of staring, re-running, blaming the file, then blaming the browser, then blaming the data, then briefly blaming each other, then making more coffee, then quietly blaming the coffee. The usual stages of debugging grief.

But here is the thing. Those five hours were the cheapest five hours that project will ever spend. Because the alternative was a customer uploading their real lead list, watching a thousand errors eat their afternoon, and never trusting that import button again. Some bugs you pay for with a few hours in testing. The same bug, found in production, you pay for with a customer.

We will take the five hours. Every single time.

The actual lesson: think like a troublemaker
If there is one thing I want you to steal from this story, it is the mindset, not the bug.

A good tester does not ask "does this work?" A good tester asks "how do I break this?" Those are completely different questions, and only the second one finds the bugs that matter.

You have to stop thinking like the developer who built it and start thinking like:

The lazy user who uploads the wrong file format because it was the first one they saw.

The chaos user whose spreadsheet has merged cells, empty rows, and a column titled "do not delete."

The bulk user who does not have 10 clean records, they have 4,000 dirty ones.

The troublemaker, the one who actively wants to see what happens if they do the thing they were obviously not supposed to do.

Software does not break on the inputs you expected. It breaks on the inputs you did not. So your job is to become a connoisseur of the unexpected. Feed it the wrong format. Feed it too much. Feed it almost-right data, because almost-right is far more dangerous than obviously wrong. Poke the thing that everyone swears is fine, especially the thing everyone swears is fine.

The features nobody tests properly are always the "simple" ones. The import button. The search box. The little form at the bottom. They look harmless. They are never harmless.
The takeaway

That import feature looked like the most boring thing on the project. One button, one file, what could possibly go wrong. The answer, it turned out, was about a thousand things, plus a Google Sheet with a grudge.
Quality is not about proving software works. Anyone can do that. Quality is about hunting for the moment it stops working, before a real person stumbles into it first.

So the next time something passes on the happy path and everyone wants to move on, be the annoying one in the room who says, "okay, but what if I upload the worst file imaginable?"

Then go do exactly that.
Your future self, and a customer you will never meet, will quietly thank you.

If you have a "simple" feature you are absolutely sure works fine, I have some bad news and a Google Sheet for you. Drop your worst "it worked on my machine" story in the comments.