How to Test App Security and Permissions as a Tester
You do not need to be a security engineer to find security and privacy issues during testing. Here is what to look for, how to evaluate it, and how to write findings developers can act on.
Your role as a tester: You are not doing penetration testing or code analysis. Your job is to observe what a real user can see, test, and experience: excessive permissions, confusing consent flows, missing authentication barriers, and data exposed in the UI.
Step one: document every permission request
The moment you first open an app, start noting every permission it requests. Record: the screen you were on when the request appeared, the exact permission requested (camera, location, contacts, notifications, etc.), and whether any explanation was provided before the system dialog.
Screenshot every permission dialog as it appears
Note what you were doing in the app when the request triggered
If no explanation appeared before the dialog, record this as a finding
On Android 13+, note if the app requests broad storage access when it only needs one file type
On iOS, note if the app requests Always On location when While Using would logically suffice
Permission red flags to look for
Camera + microphone without clear purpose
A calculator app requesting camera access has no justification. Note apps are different. In your report, describe what the app does and why the permission seems excessive.
Location requested at app launch
If the app immediately asks for location before any feature that would need it is shown, that is a UX and privacy problem. Note the exact screen where the prompt appeared.
Contacts permission for a non-social app
A contacts permission request from a fitness tracker or a game has no legitimate use. Document this.
Always On location vs While Using
Most apps only need location 'while using'. An app that requests 'always on' location (background) should have a clear justification. If it does not, flag it.
Permissions not explained before the system prompt
Best practice is to explain why a permission is needed before the system prompt appears. If the system dialog appears with no context, this is a UX issue worth reporting.
Security behaviour checks
Login / authentication flows
Test what happens after multiple failed logins. Does the app lock out? Does it show a CAPTCHA? Or does it allow unlimited attempts? Unlimited login attempts is a security gap.
Session handling
Log in, background the app for 30 minutes, return. Does it prompt for authentication again? Enterprise and banking apps should. A notes app probably should not need to. Note what you observe.
Data visible in screenshots / app switcher
Switch away from the app and check the app switcher. Sensitive content (banking balances, messages) should be obscured in the preview. If it is not, that is a finding.
Clipboard access
Some apps read the clipboard without prompting. On iOS 14+, you will see a notification if an app reads your clipboard. Note this if you observe it on an app that has no obvious reason to access it.
Network calls on insecure screens
For apps that handle sensitive data, note whether you are on a clearly secure screen (padlock, HTTPS indicator) when entering passwords or payment details.
Logout behaviour
After logging out, use the back button to try to navigate to a previously viewed authenticated screen. A properly implemented logout should make this impossible.
How to write security and permission findings
Security findings need extra precision because developers may push back if the finding is vague. Use this structure:
What I observed
The app requested 'Always On' location access during onboarding, before any location-dependent feature was shown.
When it happened
Screen 3 of the onboarding flow, immediately after the user entered their email address.
Screenshot/recording
Attach the screenshot of the permission dialog and the preceding screen.
Why it is a problem
No explanation was provided for why background location is needed. Apple guidelines require a usage description that explains the purpose to the user.
Severity
Medium: may not cause rejection, but will cause user distrust and may trigger a store review flag on iOS.
Privacy policy verification
Does the app link to a privacy policy during onboarding or signup? No link is a rejection cause.
Is the privacy policy link functional? Tap it during your test. Broken or placeholder links are a finding.
Does the policy mention the specific data the app collects? If the app requests camera access, the policy should explain why.
For apps handling children's data (games, education): verify a COPPA or GDPR-K notice is present.
Join AppTester.co as a tester
Apply to test real apps on your own device. Structured briefs. Clear payment per accepted report. Security and privacy testing included.