1. Not storing secrets properly or using hardcoded secrets

2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones

3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.

4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses

5. The list is actually very long. Just few top of my mind.

Fantastic answer thank you

Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app

My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)

Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)

Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.

Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.

I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.

WebViews are not an inherent problem, it's the system browser embedded in your app.

Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.

The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.

Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.

This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.

If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.