Obvious question: How to protect against this ?

mathgeek · 2025-01-02T12:36:15 1735821375

Build your API assuming anything public facing will be known. This includes anything downloaded to a device.

K0nserv · 2025-01-02T12:36:07 1735821367

Your first line of defence should be a secure API where an attacker doesn't gain anything by knowing it.

You can add obfuscation, but ultimately if the client is shipped to the user you must assume an attacker can reverse engineer it.

smallnix · 2025-01-02T12:26:34 1735820794

What specifically do you want to protect?

tonyhart7 · 2025-01-03T09:06:12 1735895172

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"

bandrami · 2025-01-02T12:54:22 1735822462

I find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?

quesera · 2025-01-02T15:00:00 1735830000

It's a valid desire, but you have to be really dedicated to the effort to block it, in practice.

You might intend your API to be consumed only by your own clients. E.g. your published mobile apps.

A well-designed API won't allow a third-party client to do anything that your own client wouldn't allow of course. Permissions are always enforced on the back end.

But there are many cases where a user might want a custom/different client:

If your mobile apps are not awesome, or if they deprioritize a specific use case, or if they serve ads ... or even if your users want to automate some action in your service...

If your service is popular enough (or you attract a certain kind of user), you will have some people building their own clients.

bandrami · 2025-01-02T18:37:00 1735843020

Those sound like bad use cases for a client-server model with public endpoints, then? I mean, you could cert-pin yourself in the client app, I guess.

quesera · 2025-01-02T23:37:13 1735861033

Not sure what you mean here. All endpoints are equally public.

kube-system · 2025-01-02T15:09:22 1735830562

Not necessarily. A common pattern is to build a 'private API' intended to be used by one's own front-end applications. For example: most client-rendered applications, like the Airbnb example on this page.

nsonha · 2025-01-03T05:36:31 1735882591

Modern APIs are actually most of the times poor man's RPC, they don't need to exist, much less known.

soheil · 2025-01-02T12:34:26 1735821266

[flagged]

RandomRandy · 2025-01-02T12:47:00 1735822020

You can read SSL traffic if you're able to install a root certificate on your device and the website/app doesn't use certificate pinning.

I recently used HttpToolkit to reverse engineer a REST endpoint that used SSL encryption

pimterry · 2025-01-02T12:54:41 1735822481

Even if it does use certificate pinning, you can generally disable that using tools like Frida (https://frida.re) with scripts like https://github.com/httptoolkit/frida-interception-and-unpinn...

batch12 · 2025-01-02T12:53:29 1735822409

This isn't true. Mitmproxy and burp can both proxy TLS. Maybe you're misunderstanding the use case.

iBotPeaches · 2025-01-02T12:44:16 1735821856

A good deal of APIs don't pin SSL certs so MITM works for a solid amount of them.

erk__ · 2025-01-02T12:41:11 1735821671

Only as long as you cannot load your own certificates, which you are able to in a lot of cases. Though on Android you can lock certificates allowed in a app, this can be circumvented though it adds another step. I am unsure if the same is a case for Apples devices, at least you might need jailbreak there.