Live data from Hacker News

MitmProxy2Swagger: Automagically reverse-engineer REST APIs

github.com

71–80 of 82 posts

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#71

Obvious question: How to protect against this ?

for me, we cant 100% protect again this type of usage but we can minimize with good observarbility and monitoring tools that always check if user is run this via verified way (signed app,web or etc) or RE'ing the api because guess what??? we are the creator of such system, its easy to detect bot/such case when you have good analytical data because this type of way does not give any "traces"

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#72

Earlier quoted context omitted.

> It's not very, let's say, RESTy. It has only one endpoint, To be fair, from what I understand an actual(tm) REST API would only have a single defined endpoint[1]: the entry point. With every other endpoint being discovered from the responses. And also from your message I'm guessing a URI still uniquely identifies a resource (specifically through the "query" part of the URI, instead of the more common "path"). So, t…

This is HATEOAS, basically the core feature of REST that very few people actually use. Most of what the industry calls REST or RESTful is just structured and inefficient RPC.

True, I almost never see the endpoint discovery thing, I almost forgot about it...

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#73
post #64

Earlier quoted context omitted.

> It's not very, let's say, RESTy. It has only one endpoint, To be fair, from what I understand an actual(tm) REST API would only have a single defined endpoint[1]: the entry point. With every other endpoint being discovered from the responses. And also from your message I'm guessing a URI still uniquely identifies a resource (specifically through the "query" part of the URI, instead of the more common "path"). So, t…

I don't think anyone has ever used REST in the way you are using it - the sibling comment points out that HATEOAS is probably what you mean - this generally embeds links to all resources, full data navigation, next/prev links, and so on. It is true that a proper HATEOAS client should be able to navigate an endpoint completely with just a starting address.

Yeah unfortunately despite it being part of the REST definition, nowadays "REST" has become a term that means "REST but without HATEOAS". Similar to how "API" now means specifically "HTTP API that returns JSON", or "AI" now means "Generative AI specifically".

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#74
post #15

did i miss something or why are there TWO (2) "magically reverse engineer REST APIs" projects on the HN front page right now? is there some offline beef going on? (screenshot in case this goes away https://x.com/swyx/status/1874762725383188502 )

Offtopic and meta, but, you share a screenshot using Twitter/X? That's really bizarre to me. That is all, just had to say that.

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#75
post #22

Earlier quoted context omitted.

I curious as to why people would have a public API to begin with if they wanted to protect it from people using it. Then again, why would anyone have a public undocumented API in 2024 when a LLM can give you a cli tool to auto-generate 90% of the OpenAPI spec in a couple of hours? The last question isn't serious, I've worked in enterprise for decades and almost none of the tools organisations end up buying have good…

I think you have a misunderstanding here. The API needs to be "public" because the app uses the internet to communicate back to the home server. The API is not "public" in the sense that the app developers want anybody to use it; they just want their app to use this API. So they don't write publicly accessible documentation about it because they don't want to encourage its use. A tool like MitmProxy2Swagger lets you…

Why wouldn’t you add authentication to an API you don’t want others to use?

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#78
post #75

Earlier quoted context omitted.

I think you have a misunderstanding here. The API needs to be "public" because the app uses the internet to communicate back to the home server. The API is not "public" in the sense that the app developers want anybody to use it; they just want their app to use this API. So they don't write publicly accessible documentation about it because they don't want to encourage its use. A tool like MitmProxy2Swagger lets you…

Why wouldn’t you add authentication to an API you don’t want others to use?

The web app probably authenticates using an API as well, in which case it's trivial to add that to your shadow client as long as you have the credentials.

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#79
post #75

Earlier quoted context omitted.

I think you have a misunderstanding here. The API needs to be "public" because the app uses the internet to communicate back to the home server. The API is not "public" in the sense that the app developers want anybody to use it; they just want their app to use this API. So they don't write publicly accessible documentation about it because they don't want to encourage its use. A tool like MitmProxy2Swagger lets you…

Why wouldn’t you add authentication to an API you don’t want others to use?

Laziness / skill issue.

How many apps have you seen only do client-side protection?

Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs

#80
post #15

did i miss something or why are there TWO (2) "magically reverse engineer REST APIs" projects on the HN front page right now? is there some offline beef going on? (screenshot in case this goes away https://x.com/swyx/status/1874762725383188502 )

Offtopic and meta, but, you share a screenshot using Twitter/X? That's really bizarre to me. That is all, just had to say that.

how is it worse than photobucket or imgur
Post reply on HN