Every Prisma developer has a silent risk in their codebase. A single deleteMany() with no where clause wipes an entire table. A findMany() with no limit dumps your entire database to the client. And there's a lesser known attack called operator injection, where an attacker sends { "not": "" } as a password value instead of a plain string, and Prisma accepts it as a valid query operator, bypassing authentication entirely. When tested, Prisma did not block it. prisma-firewall does.
No reviews yetBe the first to leave a review for prisma-firewall
Maker
📌
Hey everyone! 👋
I'm Neeraj, a CS student from Singapore.
I built prisma-firewall over 2 days while working on a personal project using Prisma. I kept thinking about how easy it is to make a mistake that causes real damage. A stray deleteMany() with no where clause, a findMany() that dumps your entire database, sensitive fields accidentally returned in a query.
Then I discovered something that really surprised me. There's a vulnerability called operator injection where an attacker sends { "not": "" } as a password value instead of a plain string. Prisma accepts it as a valid query operator and returns the user without ever checking their password. I tested this myself on a real Prisma setup. It went straight through.
That's when I decided to build this properly.
The goal was simple. One line to install, zero changes to your existing queries, runs silently in the background and catches what Prisma misses. A safety net for when things go wrong, because they always do at some point.
Would love to hear feedback from the community, especially if there are security edge cases I haven't covered yet. Happy to answer any questions!