Net API Notes for 2021/05/05 - Issue 161

Net API Notes is a regular, hand-curated digest of impactful news and analysis for busy API practitioners. Are you reading this on the web and not subscribed yet? Sign up today to be the first to get ad-free, actionable info delivered weekly to your inbox.

Another week, another API security event. It would be one thing if these were complex, Mission Impossible-inspired hacks. Alas, the truth is much more mundane. However, before we get to those, let's talk about some future trends.


After some time in the API space, I can appreciate how people cycle in and out; not everyone has lived and breathed APIs for the last decade+. For newer folks, Richard MacManus reintroduces John Musser, the founder of ProgrammableWeb and the current director of data and analytics for Ford's Autonomous Vehicles division.

The piece discusses several immediately relevant trends. One of these is 'Diversity of API Formats'. It is in this section that John provides one of the most succinct and memorable descriptions of the various options:

"GraphQL is when you need flexibility; gRPC is when you need performance. You also have WebSocket, optimized for event-based models, and you have webhooks, which are optimized for callback models. So you have a set of options."

Under "OpenAPIs", there seems to be a bit of a conflation between the usefulness of open formats (like OpenAPI) and Open APIs. As suggested by the article, Open APIs are situations where people could freely access and build upon a web service, circa Twitter pre-2012. The distinction is essential; with open formats, businesses will continue to reap benefits from consistent, human-readable, and machine-parsable interface descriptions. But we're not returning to a world of free, unrestricted access anytime soon.


If you've spent any amount of time in the API design space, you're likely to have come across the concept of consistency. Maintaining a consistent affordance throughout designs is important, particularly in large, internal use cases. A resource naming scheme may imply which actions can be taken on that resource, for example.

However, what happens when you aggregate across different companies' styles? APIDeck has a fantastic example of what working across different pagination affordances looks like.

The article, written by Elias Meire, first covers the four major pagination styles that APIDeck aggregates. There's also a helpful discussion of the various pros and cons of each approach. Finally, it ends by talking about the direction that APIDeck chose to expose in their solution.

I especially appreciate the discussion of page limits. I've seen firsthand how callers abuse server resources and turn a web request into a batch operation by abusing pagination without return limits. Just because you are unaware why anyone would call 10,000 records at once doesn't mean it isn't someone else's use case.


There are two major API security stories this week. We'll start with the bigger forehead-slapper first.

As reported on the KrebsOnSecurity website, a sophomore at the Rochester Institute of Technology named Bill Demirkapi discovered he could call an Experian API without any authentication. By providing a name and current mailing address, anyone could fetch a current credit score and a list of recommended actions to improve it ("limit number of revolving credit lines", "lower percentage of used credit", etc.). The API also asks for a birth date, but entering a string of zeroes allows any caller to bypass that check.

While Experian was quick to identify and restrict API access to the site where the issue was discovered, it is unknown how many other clients continue to use the leaky endpoint. Bottom line, the authentication factors at play were weak considering the information involved. For example, a nefarious individual could programmatically cycle through addresses and use the API to confirm somebody's residence to dox them.

Moving on, in the last notes, I mentioned John Deere was struck with a BOLA attack (BOLA stands for "Broken Object Level Authorization"). It turns out the President's exercise bike of choice, Peloton, also has an API that doesn't perform appropriate authentication. The API allowed anyone to retrieve any other Peloton user's age, gender, city, weight, workout statistics, and - in some instances - birthdate. All of these are useful for identity theft.

That's alone is pretty bad. However, what's worse is that the vulnerability was reported on January 20th. Security researchers customarily give companies 90 days to fix the problem before announcing the issue publicly. As reported by TechCrunch, the vulnerability was not addressed until reporters contacted Peloton for comment after the 90 days were up.

Now that the hole has been closed, additional information is available on the Pen Test Partners site. Among the details mentioned, additionally, there were a number of unauthenticated GraphQL endpoints.



Hello to the Belgium API community! I see you! Your online meetup is the latest event added to If you know of an upcoming API event, whether online or in physical space, let me know, and I'll get it on the list.

I'll end, as always, with a thank you to my Patreons. You keep the newsletter remains free of advertising, information selling, and outside a paywall. Because of you, the rest of the community benefits.

Till next time, Matthew

@libel_vox and While I work at Postman, the adorably powerful API platform company, the opinions presented above are mine.

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.