25 Findings, One Mobile App: What a Real Pentest Report Taught Me About React Native Security

A few weeks ago I sat down with a full penetration test report on a tenant app I’d been building. Twenty five findings. One critical. The rest spread across high, medium, and low. On paper that’s a checklist. In practice, fixing it taught me more about how an app breaks than any code review has.

Here’s what actually hurt, and what it took to close it.

The critical one was account takeover, from something deceptively small. The forgot-password flow leaked a user’s internal ID. The change-password flow never asked for the current password. Neither is dangerous alone. Together, anyone could grab a user’s ID on one screen and walk into their account on another. Fixing it meant relearning a rule: never let one endpoint hand out an identifier another endpoint will trust blindly.

Then the IDOR on password generation. Tamper the last two digits of a user ID, and you’re looking at someone else’s name, email, phone number. It wasn’t a missing feature, it was a missing check. The server assumed the ID belonged to the person making the request. It never asked.

The file upload issue made me rethink how I test entirely. I’d been validating file type on the picker and calling it done. Turns out that’s decoration, not defense. A file could carry a different payload than its extension claimed, and the server accepted it, stored it, served it back. One uploaded PDF came back flagged by multiple antivirus engines as malicious. That’s not a UI bug. That’s a pipeline that trusted the client.

Rate limiting looked cosmetic until I automated a request. Adding co-occupants, generating passwords, none of it had real throttling. An attacker doesn’t need to be clever if the app just lets them try a thousand times.

And the quieter ones. Sensitive data unmasked in API responses, passport numbers, IBANs, visa details, sitting in plaintext. Session tokens that outlived logout. A “Hotfix” debug feature left open on the login screen, dumping request and response logs, headers, tokens, for anyone who tapped it.

None of these feel dramatic alone. Together, they’re the difference between an app that looks secure and one that actually is.

What fixing this came down to was refusing to trust anything the UI promised. A required-field asterisk means nothing if the backend accepts the request without it. A file filter means nothing if the server never checks what’s inside the file. A password field means nothing if the endpoint next to it will change it without asking who’s asking.

The work wasn’t glamorous. It was going endpoint by endpoint, asking what happens if I lie to this request, and closing every gap where the app took my word for it.

If you’re building anything that touches identity, payments, or lease data, ask this before a pentest report tells you the answer: does your UI enforce this rule, or your server?