| ▲ | nicce a day ago |
| > You just install it on your phone and use the app. Some people on the cybersecurity side are starting to cry.... |
|
| ▲ | user43928 a day ago | parent | next [-] |
| I have been getting these comments often here, including concerns about my non existent backend's security. Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation. I found the concerns again wildly overblown. |
| |
| ▲ | joenada 14 hours ago | parent | next [-] | | You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data. | |
| ▲ | freeplay a day ago | parent | prev [-] | | But what if someone discovers a iOS 0day worth several million dollars and burns it to compromise your app specifically? /s |
|
|
| ▲ | chis a day ago | parent | prev | next [-] |
| Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend |
| |
| ▲ | nicce a day ago | parent | next [-] | | 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. | | |
| ▲ | Matumio 16 hours ago | parent | next [-] | | 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".) | |
| ▲ | user43928 15 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | rudedogg a day ago | parent | prev | next [-] | | 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 | |
| ▲ | chis a day ago | parent | prev [-] | | Fantastic answer thank you |
| |
| ▲ | freeplay a day ago | parent | prev [-] | | Nailed it. Assume your client is compromised and/or malicious regardless of how it was built. | | |
| ▲ | asdfsa32 21 hours ago | parent | next [-] | | 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. | |
| ▲ | Matumio 16 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | Culonavirus a day ago | parent | prev | next [-] |
| They better start a proper hydration regime because they'll be crying a lot. |
|
| ▲ | Perz1val a day ago | parent | prev [-] |
| Why? The api has to be secure. Mobile os keeps the app safe. Where is the attack surface? |
| |
| ▲ | nicce a day ago | parent [-] | | You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help. | | |
|
