API expert says 'This is the one thing we didn't want to happen.'

I’d been using Postman since the start of my career, when it was a handy, lightweight tool that did one thing really well: Sending REST requests and capturing API responses. Sadly, it became yet another victim of the Silicon Valley Lifecycle (’enshittification’ is such an over-used term): It became too popular, acquisitions happened, divorced-from-reality valuations were made, VC became involved, and the once-perfect application became a degraded monetised version of itself. One particular change, though, created a huge problem for engineers using Postman on corporate networks.

Almost all API secrets I come across have admin-like permissions attached to them, meaning anyone with access to a secret could read, write, modify and delete whatever data they wanted on whichever system. In an ideal world, each API secret would provide the least privilege, but the reality is engineers can have 101 things using a given API. The risk of a hacker actually exploiting that is very low, assuming the system is well-engineered, and assuming the API secrets are stored securely enough.

So, as one could imagine, myself and colleagues put considerable effort into protecting API secrets from disclosure, because of the gravity of what could happen if the wrong person accessed them. Organisations should have a clearly defined policy about where and how API secrets stored, and that should be in the most secure method of storage possible.

Postman can’t be used as an offline application, and all the users’ API endpoint addresses and their secrets are uploaded to Postman’s servers by default. In most cases (and I suspect by design), that happens long before a developer notices there’s a very small icon for a local storage method.

As far as I can tell, Postman doesn’t use end-to-end encryption for this, and the level of security Postman claims to offer is only provided with the most expensive subscription. Think about that: Postman uploads all our shit, without our explicit consent, and we’re expected to pay for the privilege of not having that completely break our organisation’s security model. The main point, though, is that our API secrets should not be on Postman’s servers in the first place.

On a corporate development team, there will always be developers/engineers registering Postman accounts with personal email address that aren’t protected by MFA. Secrets for maybe half a dozen APIs are going to be uploaded to at least one of those accounts. Multiply that by the number of corporate development teams out there, and it becomes apparent Postman’s servers are a prized target with a large attack surface. I see that as a potentially catastrophic data breach waiting to happen. We’ll no doubt hear and read of such an incident in due course.

So, we needed to go looking for alternatives. The safest bet for now is to use cURL, with a personal repo of scripts, and pipe the API responses to a JSON file. That could be done in BASH and PowerShell. I’m working on a personal API testing application (using .NET, of course), but haven’t got round to finishing it. Most my colleagues are using Bruno as the main replacement, which may or may not go the way Postman did anytime soon. One thing I really like about Bruno is it can generate an implementation of the HTTP request in any of the mainstream programming and scripting languages. Just select ‘Generate Code’ from the menu, on any HTTP request within a collection, and we get code that’s known to work with an API.