Launch HN: Escape (YC W23) – Discover and secure all your APIs
Here is our demo: https://youtu.be/qcCaegVElTY
Typical modern large orgs have hundreds if not thousands of APIs, and many of those handle sensitive data or are critical to business operations. The development of those APIs is distributed across different development teams that don’t always have knowledge of API security best practices. API source codes are updated frequently, making it easy for new, easily exploitable security vulnerabilities to be introduced in production environments (think the 2018 FB 50M accounts data leak).
APIs make up 80% of global web traffic, and this share is growing. The responsibility for securing APIs is usually given to the organization's security engineers, not the API developers, which makes sense because they’re the ones who know how to secure things. But in practice, it is almost an impossible job because the security engineers have no way to track everything the developers are exposing online, and usually, there’s nobody to tell them! And when they do find out, they lack the right tooling for achieving it. This is a huge risk for organizations, a pain and personal risk for security engineers, and a great technical challenge.
Working as a software engineer a few years back, I faced a data scare: a pharmaceutical client's data was compromised due to a NoSQL injection. In this case the damage ended up controlled, but it led to the nightmarish thought of waking up one day with all the data from the applications gone, simply because cybercriminals exploited a security issue. When looking for solutions that allowed developers to ensure what they released in production was secure, we couldn’t find anything particularly good. Security scanning tools like OWASP ZAP had been designed for people with penetration testing backgrounds. Code scanning tools were only finding the low-hanging fruit at the cost of many false positives, and ended up resembling security-oriented linters, turning the entire IDE red for minimal value. It felt like none of the existing security tools were built with real engineers in mind. When I met Antoine, who had previously been a security engineer at NATO and Apple, we decided to tackle this issue together and create a modern security tool that would appeal to both developers and security people. It needed to be fast, easy to set up yet configurable, have outstanding support for securing APIs, and find what was relevant with a low false positive rate.
The first step was to show security engineers and developers what APIs they had to secure. We needed to find an easy way to discover any organization’s exposed and internal APIs.
To discover all APIs, we crafted a system that extracts all the API routes the organization exposes by scanning its domains, frontend websites, and SPAs. It then enriches this data by connecting to code repositories, API gateways, and API development tools to create a full list of all the exposed endpoints and the sensitivity of the data they handle. Other testing tools do not provide an inventory of all the API routes exposed by an organization, but as we mentioned above, the biggest problem security engineers face is often just finding out what it is they need to test!
Then, we needed to provide security engineers and developers with a list of security issues in their APIs.
Since APIs act as a business model layer, most of the critical security issues lie in the business processes underlying APIs. In security, issues obtained from breaking business processes are called Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA), and Broken Object Property Level Authorization (BOPLA).
To find them, we knew we couldn’t rely on traditiona...
39 comments
[ 6.8 ms ] story [ 88.3 ms ] thread:))) whats wrong with my not-professional email address?
Mind you that you can also use your personal GitHub account to register because we noticed people are way less likely to do risky stuff with their Github account than with a personal email :)
[1] https://escape.tech/blog/rest-security-testing/
edit: some of those comments have now disappeared. Make of that what you want.
I've emailed the founders to tell their friends/teammates/etc. not to do this.
Since the purpose of voting rings is to try to get on the front page, that construct doesn't really apply here, unless you want to call "automatic placement" a "ring".
People who don't know HN's rules often try to "help" in this way. I try to tell everyone that it doesn't help, it hurts! but it's hard to get the word out.
(Edit: forgot to mention that the comments disappeared because HN users flagged them enough to make them [dead]. You can see [dead] comments if you want to, by turning on 'showdead' in your profile. That's also in the FAQ: https://news.ycombinator.com/newsfaq.html)
I guess we can be proud that they are our users and wanted to help. There was no intent to break HN's rules. We apologize for that happening, and we have told them about the rules so it doesn't happen again.
Although, by nature, the security market is mostly enterprise, we do have plans for startups and SMB as well. Happy to have your feedback on our pricing btw, always something hard to get right.
I understand the potential market, however, as a startup, I probably wouldn't (and won't) sign up because I have been burned too many times when companies pivot to enterprise pricing only (i.e. Hasura) and it doesn't give me much confidence there would be a reason for you to continue supporting those plans since it's not the focus of the company based on not even having pricing on the home page.
Not a critique, just some feedback :)
If I understand the product correctly, you're suggesting customers opt into letting an LLM pentest their testing systems, and allowing that LLM to generate and carry out plans of attack.
Imagine a recurring revenue business that keeps tokens for user credit cards on file, and then a dev naively gives the CI infrastructure an ability to call out/proxy some calls to production in a privileged way, and then Escape finds a way to break out of CI and charge cards on the production system. Of course, this is a massive security issue in and of itself, but at a certain point, a human pentester would know "holy ** I should stop what I'm doing right now." How do we know that Escape won't keep fuzzing and fuzzing and exacerbate the situation, causing real-world impact to customers?
There's probably a philosophical take on this - that security by obscurity is no security at all, and that threat actors will be every bit as good at this as Escape's technology is. But for any business that's not really a dedicated target for actors (say, only gets drive-by script kiddies that are easily fended off by keeping software up to date) using Escape might be increasing their risk of a breach that is meaningful to their customers, by inviting the scrutiny of a well-funded LLM, with a laser focus only on your specific business, that doesn't know when to stop.
You are right in the sense that using automated security testing tools in production creates a risk. But there are workarounds:
1) Most of Escape's security scans happen on staging or pre-prod environments, where there is little risk of breaking something critical or finding real customer data.
2) We have designed a specific scan mode for production APIs, that is made with safety in mind. It will not attempt the riskiest attack scenarios and, thus will be safe for production use at the cost of scanning depth.
You can chose a scan mode when adding a new application for testing in Escape. So far, most of our users use both modes, one for the production environment and one for the development environment, to spot bugs early.
No user ever had problems with the production scanning mode.
By the way, the core algorithm powering Escape is more a graph traversal algorithm than LLMs. We do use a small, self-hosted LLM for specific inference tasks, but everything is made in-house, and we don't use OpenAI or any other inference API.
Hope that helps!
What does that mean exactly?
Do you manually assess what is risky for a particular API, or is it up to the system to choose?
If it's up to it, what happens if it thinks that's not risky to delete user data?
You can also manually configure an allowlist/blocklist of operations for specific use cases.
Of course, for investors, we would have written things differently, but we are not looking to raise money at the moment.
Hope that makes it more clear!
I’ll test it out with them and see what they think. I will say that we were originally exploring Bright, but we had to rely on telling them what APIs and endpoints to hit, and they wanted to embed an engineer with us to help us onboard their product.
We wanted something simple that we could pay money for, have it discover all of our endpoints, pentest, and return a report.
1) please move pricing onto main site 2) please consider deploying on Azure Marketplace
The fact you’re including GraphQL is a big positive too.
We try to make our product as straightforward as possible. It’s a long journey for such technical topic but it gets better everyday.
And we listen to feedback. I’ll take a look at Azure Marketplace.
Since then, we have completely revamped it to create py-multiauth v2 that supports basically all form of authentication as you can see in the docs https://docs.escape.tech/authentication/
py-multiauth v2 is not open source for now, but our eng team might be ok to open source it if there is interest from the community
Hope that makes it more clear!