Download the Charles app on your iPhone, turn it on, use the app you’re interested in, then look at Charles to see what network calls the app made while you were using it.

Or install MITMProxy on your laptop, install your newly-generated root CA cert on your phone, and point your phone’s http proxy to your MITMproxy port. I prefer this to installing an app on my phone.

Surely the phone notices that the root certificate is not one of those it already knows about?

All the device knows is that it trusts some root CAs and not others. You add your personal root CA to the trusted list; so it's trusted.

Unless the site uses some kind of certificate pinning (c.f. HPKP), one trusted root is as good as another.

This is how TLS inspection is done on corporate networks. IT will apply a group policy that puts a company-owned root certificate into the trusted roots on your Windows machine - maybe the same one that's used for the rest of your internal PKI.

You then issue a subordinate CA from that root, and your web proxy infrastructure (Bluecoat or whatever) then uses that CA to do just-in-time provisioning of certs for whatever domains you're intercepting.

The phone doesn’t, as the sibling comment mentions, but the app might (if it’s doing certificate pinning).

Does this work with SSL-pinning enabled?

No, I believe you would have to recompile the app with your cert or use Frida or something to hook the cert check function.

Wow this is very useful and I’ll definitely try that app to see which apps are making what network calls

Apps are built in a client-server configuration where the app is the user facing client and the API is the server. If you listen and manipulate the data sent back and forth to the server you can often do a lot more then what the user interface allows. Whether that’s gathering and analyzing more data or completing actions the server developers never anticipated the client would attempt.

Simply put backend developers assume the client will only do what they configure it to do and won’t be tampered with, except with enough effort it can trivially be tampered with.

> backend developers assume the client will only do what they configure

... if they lack the time (or inclination) to validate the requests properly. Client side validation is important for good UX, but not strictly essential, whereas server side validation ought to be mandatory.

Put more generously there are limitations to the apple development ecosystem and frameworks, and limitations to web frameworks. Combined you combine both sets of limitations - which encourage the developers to throw their hands up.

Release engineering mobile apps is a PITA. Backend engineering at a mobile first company is often second fiddle.

I'm not sure how Apple's ecosystem or web frameworks limit the validation on a backend, which is pretty much platform agnostic. The limitations are bound by what a HTTP response can provide, and the error states the front-end devs are willing to handle. During my time as a mobile/web dev, the back-end devs were always compliant with providing the error information where relevant, and would enforce business requirements (e.g., paid users are only authorized to do 'x') on the back-end. Once again, it's more expedient to not care, but I think Bumble has the budget and self-interest to care for the examples in the article.

“We should probably ______ , but _____ ...”

You can do it a few ways, you can do it as simple as modifying the headers and the get via firebug or such.

https://code.tutsplus.com/tutorials/http-headers-for-dummies...

You can also capture and analyze network traffic and inject other stuff too.

Basically basic OWASP stuff. If the app relies on client side, then the server will trust it 100% of the time and you can do much more.

If you are a backend developer, never trust client-side. Never.

Thank you for asking this question. I have learned a lot from this thread :)

You are welcome and same here the community has been really helpful this is why I love HN