What building a browser extension taught us about real web attacks
We started Nautillo as a browser extension to see how security issues appear during normal browsing.
We learned this fast.
Tools scan in isolation.
Attackers chain small weaknesses step by step.
So Nautillo is evolving.
From one extension to attack focused security.
Extensions for early signals.
A SaaS product that simulates real web attack paths.
Question.
How do you validate real security risk today without enterprise tools or noisy scanners?
Trending on Indie Hackers
One thing we see a lot on the server side is extensions becoming the weakest link after a user session is already trusted. Token reuse and silent background requests are especially nasty because logs look clean unless you’re watching outbound behavior closely. Curious if you saw similar patterns.
Yes, we see similar patterns.
Once a session is trusted, browser side behavior blends in.
Single actions look harmless. Chained paths change the risk.
Our focus stays on surfacing early signals and validating impact.
If a path reaches something sensitive, the risk is real.
Really interesting pivot from extension to SaaS. The attack path simulation angle is smart — most tools just throw a list of CVEs at you without context.
To your question: I've been validating JSON payloads lately and the amount of sketchy data that passes through APIs is wild. Simple stuff like checking for script injection in JSON fields catches more issues than you'd think.
Curious — does Nautillo work with API traffic too, or mainly browser-based attacks?
Thanks. That pivot came directly from what we saw in practice.
You are right about APIs.
A lot of real impact starts in JSON, not the UI.
Loose validation and trust in client side logic show up fast.
Nautillo PRO is not browser only.
The simulations operate at the HTTP layer.
That includes:
• REST and GraphQL endpoints.
• JSON input handling.
• Auth and session flows reused across APIs and web.
• Business logic paths that never touch the frontend.
The browser extension helped us spot early signals.
The SaaS focuses on how those signals turn into full attack paths.
API abuse is a big part of that.
Especially where small issues chain into access or data exposure.
The "chain small weaknesses" insight is the key differentiator here. Most security tools treat vulnerabilities as isolated findings — "you have XSS here, SQL injection there" — without showing how an attacker would actually combine them into a kill chain.
To your question about validating security risk without enterprise tools:
For small teams, I've seen a few approaches work:
Threat modeling first — Before scanning anything, map out "what would an attacker actually want from this system?" That filters signal from noise better than any tool.
Bug bounty programs at small scale — Even a modest bounty attracts researchers who think like attackers, not scanners. They naturally chain weaknesses because that's how you find interesting bugs.
Dependency-focused audits — Most indie apps get compromised through supply chain, not custom code. Monitoring your npm/pip/etc dependencies for known vulns is high ROI.
Curious about the extension → SaaS pivot: what's the distribution strategy for the SaaS side? Security tools are notoriously hard to sell — buyers want proof you can find real issues, but you can't demo on their production systems without trust first. Chicken-and-egg.
You are right. Chaining is where real risk shows up.
We focus on the first step.
How an attacker finds your app on the internet with no inside knowledge.
Then we show how small weaknesses connect until the path reaches sensitive data.
Your approaches match what we see.
Threat modeling sets intent.
Bug bounties surface real attacker thinking.
Dependencies often provide the first foothold.
Our approach:
• Safe, non destructive simulations.
• Black box.
• Clear scope and explicit consent.
• Proof of impact without damage.
The SaaS answers one question.
How far does this go if someone pushes?
"How far does this go if someone pushes?" — that's a powerful positioning. Most security reports give you a list of findings. This gives you a story of what could happen.
The black box + explicit consent approach makes sense for the trust problem I mentioned. You can demo on staging/sandbox environments without touching prod, and the consent framework builds credibility before they let you near real systems.
One follow-up on distribution: are you targeting technical founders who can evaluate the findings themselves, or security-conscious buyers who need to justify the purchase internally? The messaging might differ — technical folks want depth (show me the attack path), while buyers want risk framing (this could cost you $X in a breach).
Interesting space. Security tooling is usually either "enterprise expensive" or "free but noisy" — there's room for something in between that thinks like an attacker but communicates like a consultant.
Exactly.
We always ask for consent. Attackers do not.
Our view is simple. It is better for founders, tech leaders and teams to see the attack path themselves first. Before someone else finds it on the open internet.
On distribution, we start with technical founders and teams.
They can evaluate the depth. They understand the paths. They fix fast.
The output is still framed in impact. What data is reachable.
What access is gained.
Security reports list issues. We show the story of what happens if someone pushes.
Starting with technical founders is the right call. They can evaluate depth, act on findings quickly, and become organic advocates if the tool delivers.
The "story of what happens" framing is strong. Security reports that just list issues often get filed and forgotten. A narrative showing "here's how an attacker chains these into real access" creates urgency and clarity.
Interested to see how this evolves. Good luck with the launch.
Thanks. That is exactly the bet.
We are releasing very soon. There will be a free version.
You are welcome to try it yourself.
Will definitely check it out when it launches. The free version is a smart move for building trust in a space where buyers are naturally skeptical. Looking forward to seeing how it evolves.
Thanks, appreciate that.
We are live at nautillo.pro.
There is a free version so you can try it yourself and see the attack paths end to end.