Prompt
to protect

Continuous protection. When you first connect your app, Patchstack scans it and mitigates all known vulnerabilities to date. From there, it keeps regularly checking your app and blocks any new vulnerabilities.

Vulnerabilities are weak spots in the packages your app is built out of. It's not something you did wrong, but a flaw in the package's code. The problem is that attackers can find vulnerable packages and then launch mass attacks against as many websites online that use the same package to exploit the vulnerabilities. That's what we're stopping.

Yes. If your site is online, it's at risk. Hackers don't only launch targeted attacks: they mass-target as many sites online as possible. If your site has a vulnerable component, it could be compromised.

No. We don't touch your code. We watch for attacks and block them in real time — nothing gets rewritten, nothing gets rebuilt or redeployed. For hardening, we don't touch your code either. Masking replaces the secret and leaves the rest of the response intact. Where the sensitive material runs past what we can cleanly mask, such as a private key, a database connection string, or a stack trace, we withhold that response instead. Your code and your deploy are untouched either way. The one exception is a small set of early-warning checks on incoming requests, which we deliberately watch on real traffic before letting them block anything.

No. We block attacks against that vulnerability, so you can update it on your schedule while Patchstack protects you.

Both, in different ways. For known vulnerabilities, we cover the shared packages your app is built on; those are the highest-value targets, because one flaw reaches hundreds of thousands of apps at once. For your own code, including anything an agent wrote mid-session, our hardening rules watch what your app actually does: a leaked key, a stack trace, an outbound call somewhere it shouldn't go. We don't need to have seen your code before to catch those.

Vulnerability mitigation stops known weak spots in the building blocks your app is made of (packages). Hardening checks how your app itself is set up — things like whether an API key is accidentally left visible in a response, or whether your app can be tricked into calling internal infrastructure it should never reach. Different problem, same goal: nobody gets in. We protect you against both.

Right now we check for mistakes like secrets accidentally leaking out in a response (like an AWS key or a Stripe token), internal error details leaking out (stack traces that reveal how your app is built), your app being tricked into calling internal cloud infrastructure it should never reach, and a couple of early-warning patterns in incoming requests that often show up before an attack. Leaked secrets and internal error details are stopped automatically the moment they'd leave your app. Outbound calls to internal cloud infrastructure are blocked outright. A third group of checks, for prototype pollution and directory traversal patterns in incoming requests, is in a watch-and-learn phase. These patterns show up in ordinary traffic too (a docs page or a file browser can contain them legitimately), so we're confirming they don't fire on real users before letting them block anything.

Yes, and you'll understand what we blocked at a glance. You don't need to understand packages, dependencies, PRs, or anything else. Every app built with AI comes with hundreds of small building blocks under the hood — some of them are exploitable. We handle finding and blocking that; you don't need to understand it.