It was an ordinary Tuesday. The API was running, tests were passing, Docker came up on the first try. We were already imagining our first clients — B2B integrations, Telegram bots, deals.
Then someone on the team said: "What if we try to break everything first?"
Good idea. It almost always turns out things break faster than you expect.
What We Were Building
An analytical API for assessing Solana token risks. Not another contract scanner — there are dozens of those. We do behavioral analysis: who's behind the token, what's the history of that wallet, does the pattern resemble known manipulation schemes.
Over several months we built a database, trained a classifier, stood up a NestJS API with PostgreSQL and Redis, wrapped everything in Docker. By all indications — production-ready.
By all indications.
Hour One. "Wait, You Can Actually Break This"
We found the first vulnerability almost immediately. Not because we searched long — we just looked at the code with fresh eyes.
Our API accepts a Solana token address in the URL and passes it to an external script for analysis. It looked something like this:
const output = execSync(
node -e "fetchData('${mintAddress}').then(...)"
);
See the problem? We were inserting a string from an HTTP request directly into a shell command. Without any validation whatsoever.
In theory, anyone who knows our endpoint address could send something like '); rm -rf /app; node -e (' instead of a token address — and that command would execute on our server. It's called shell injection, and it's one of the oldest vulnerabilities in the book.
We had been running for several months. This code had been there the whole time.
It was a little unsettling.
Fixed it in twenty minutes: added a format check before touching the input at all. Solana addresses are base58 — a strictly defined character set. Everything else gets an immediate 400.
typescriptif (!/^[1-9A-HJ-NP-Za-km-z]{32,44}$/.test(mintAddress)) {
throw new BadRequestException('Invalid mint address format');
}
Simple. Effective. Should have been there from day one.
Hour Two. When Everything Works, Just Not the Way You Think
The second finding was subtler. Looks harmless on the surface. In practice — a ticking time bomb.
NestJS has a Dependency Injection mechanism: you register services in modules, the framework figures out who provides what to whom. Convenient. But we had registered the same service in two places at once.
What happens in that case? NestJS doesn't complain. Doesn't warn you. It just quietly creates two separate instances of the same service.
Sounds benign. But our database service holds a connection pool to PostgreSQL. Two instances — two pools. Under load, that means twice as many open connections as planned. PostgreSQL has a limit on simultaneous connections. Exceed that limit and the database stops responding.
We would have discovered this at three in the morning when the first client complained the API was down.
Hour Three. When "All Green" Is a Lie
The next discovery was, perhaps, the most uncomfortable. Not because it was dangerous — because it was embarrassing.
We have a list of known exchange and bridge addresses. If several large buyers of a token were funded from one of these addresses — that's normal, that's not insider collusion. Sound logic.
But when we opened the file with those addresses, here's what we saw:
typescriptconst BRIDGE_ADDRESSES = new Set([
'BLZRi6frs4X4DNLw56waFf6jNav84j6bKrikoZejset5', // Mayan — real
'debridge...', // ← literally three dots
'worm...', // ← three dots again
'binance...', // ← and again
]);
Someone at some point wrote a placeholder instead of a real address. And forgot. Tests didn't catch it because tests didn't know what a correct Wormhole Bridge address was supposed to look like.
The code compiled. The service started. The function was called. Results were returned. Everything was "green."
And everything was wrong.
Three out of four addresses in our protection list didn't exist. Any coordinated buying scheme through those bridges would have gone undetected.
We spent an hour finding real verified addresses and replacing the stubs with actual data. Tedious work. But exactly these tedious things stand between you and a reputational disaster.
Hour Four. The Detective and the Unreliable Witness
Probably the most interesting finding — and the hardest to debug.
One of the key elements of our analysis is determining the token creator. Who launched this memecoin? What's their history? Have we seen this wallet before?
The algorithm was straightforward: page through the token's transaction history from the end backward, find the very first one — that's the creation transaction, its initiator is the creator.
The problem surfaced by accident. We made three consecutive requests to the same token and got three different creator addresses.
One token. Three requests. Three different "creators."
The investigation took a while. Turns out: the algorithm paged through history in batches of 1,000 transactions but made a maximum of three batches. For popular tokens with thousands of transactions, the algorithm simply never reached the very first one — and each time returned a different result depending on which transactions ended up "last" in the pagination.
Imagine a detective questioning witnesses in random order and getting different testimony every time. Not because the witnesses are lying — he just talks to different people each time.
The fix was straightforward: increase the batch limit from three to ten. Now the algorithm always reaches the beginning of the history. Three requests — one result.
Hour Five. The Things You Don't Think About Until It's Too Late
The rest of the day went to what most developers put off "for later." Things that seem obvious when you read about them — and that you don't think about when you're writing code at two in the morning.
API without rate limiting. Our endpoint was open to any volume of requests. A single script could take down the service with endless calls or exhaust the limits of the external APIs we depend on. We added 60 requests per minute per IP — standard protection, but it wasn't there.
No security headers. Browser clients received no security policy instructions whatsoever. We added helmet — one line of code that closes an entire class of browser-based attacks.
500 instead of 400. When a request came in for an unsupported blockchain, our API returned 500 Internal Server Error. Not because something was broken — we were just throwing a plain Error instead of a BadRequestException. For an integrator, the difference between 400 and 500 is fundamental: the first means "you did something wrong," the second means "we crashed."
The Tally: Seven Hours Against Seven Vulnerabilities
By evening we had seven closed items and one uncomfortable realization.
We hadn't done anything exotic. We hadn't used unvetted libraries. We hadn't reinvented the wheel where we didn't need to. We just wrote code — the way most of us write it in "ship the feature" mode.
And in that code lived perfectly classic vulnerabilities. Shell injection from a 1998 textbook. Provider duplication that doesn't complain but breaks logic under load. Stubs in a critical place that nobody replaced.
All of this would have been discovered by the first clients. At the worst possible moment. When fixing it would cost far more.
The most important thing we learned: a security audit isn't about hunting exotic zero-day vulnerabilities. It's about slowing down and looking at your own code like a stranger would. What here was done on autopilot? What was a "temporary solution" three months ago? What do tests not check — because they don't know what to check for?
Seven hours of work. Seven findings. Not one of them required genius — just attention.
The project is currently in closed beta. Due to the nature of our security research and the uniqueness of the underlying classification methodology, only a partial overview is made available to the public at this stage. Core components — including the behavioral classifier, archetype definitions, and wallet dataset — remain proprietary. We'll announce the public launch and partnership opportunities separately.
Originally published on Coder Legion.
