You built a working app. It looks good, it functions well, and you are ready to submit it to the App Store or Google Play. Then it gets rejected. Not for bugs or bad design, but for a security or privacy issue you did not know existed.
This article shows the security tests, free tools, and store requirements to check before submission. You will learn which vulnerabilities commonly trigger rejection, which free tools catch them, and what Apple and Google require before they approve your listing.
Recent platform reviews show the scale of the problem. In 2024, more than 1.9 million submissions were rejected for failing to meet standards, including privacy violations. That same year, Google blocked 2.36 million apps from publishing for policy violations. Most launch-blocking security issues are preventable if you test configuration, secrets, storage, and privacy disclosures before review.
Five vulnerabilities that actually get indie apps rejected
Most indie app rejections come from a short list of preventable security mistakes. The biggest risks are exposed secrets, weak access control, insecure defaults, plain-text storage, and missing privacy disclosures. The OWASP Mobile Top 10 lists these risks, and they map closely to mistakes small teams often make before launch.
Exposed API keys (OWASP M1)
Your app uses secret keys to connect to services like payment providers, backend services, or messaging tools. If those keys sit in your frontend code, anyone can extract them. The OWASP citizen development guide warns that credentials get exposed when authentication and authorization are handled in an overly permissive, opaque, or overly complicated way.
Fix: Store API keys in server-side environment variables. Do not place them in visible workflows or client-side data sources. Rotate any key that may have been exposed.
Users can see each other's data (OWASP M3)
Broken access control is a major security risk. In app projects, this usually means a database without privacy rules, which lets any logged-in user query another user's records.
Fix: Default every data type to "no one can see this" and grant access explicitly. Hiding a UI element does not protect the underlying data. Test by logging in as a second user and attempting to access the first user's records.
Shipped with insecure defaults (OWASP M8)
Default settings often favor speed during development, not production security. If your database rules still allow open reads and writes from testing, anyone can access or change that data without logging in.
Fix: Audit every database permission before launch. Use your database rules testing tools to test your security rules. Log out of your app completely and confirm no private data loads.
Sensitive data stored in plain text (OWASP M9)
Plain-text storage turns a database leak into direct exposure. The OWASP Mobile Application Security testing standard documents unsafe data handling in local storage and backups as specific weaknesses.
Fix: Do not store raw passwords. Use your platform's hashing-based authentication. Do not store payment card numbers. Use Stripe or equivalent tokenization instead.
Missing privacy controls (OWASP M6)
Privacy disclosures can block launch even when the app works. The Google Play privacy policy requirement applies even if you believe you collect nothing, because included SDKs may collect data on your behalf.
Fix: Request only permissions your app genuinely requires. Write a privacy policy that names every third-party service receiving user data, including analytics and error tracking tools.
These five checks catch many of the technical mistakes that trigger rejection before a reviewer even looks at your broader submission details.
Free tools that catch the worst problems
You can catch many launch-blocking security issues with a small set of free tools. Use the options below to choose a scanner for the common problems above before you spend time on a paid audit.
ImmuniWeb mobile app security test
The easiest starting point. No account, no setup, no code knowledge. Upload your APK or IPA file at ImmuniWeb Mobile, and it scans against the OWASP Mobile Top 10. Download the PDF report and fix anything flagged as High or Critical.
MobSF (Mobile Security Framework)
The deepest free scan available. MobSF performs static and dynamic analysis, and its static analyzer checks for hardcoded secrets, insecure data storage, weak cryptography, and dangerous permissions. It can use Docker for an easy setup that takes two commands, but Docker is optional. Reports export as PDF.
AppSweep by Guardsquare
Free with no restrictions on scans and no team size limits. AppSweep maps findings to OWASP MASVS categories and provides fix recommendations. It works well for ongoing scanning during development, not just a one-time pre-launch check.
Two more worth bookmarking
- OWASP ZAP: Tests your backend API for injection flaws and authentication weaknesses. Only relevant if your app has custom REST endpoints.
- OWASP MAS Checklist: The OWASP MAS Checklist helps you walk through the main review points in a structured way.
These tools cover many common issues, but they do not replace judgment about how your app actually works.
Automated tools miss business logic flaws specific to your app's design. For apps handling health data, financial data, or payments, a one-time professional penetration test before launch provides coverage no scanner can replicate.
What Apple and Google will reject you for
A clean scan does not guarantee approval. Store review issues can still block launch when the code looks fine, and the main blockers are incomplete disclosures, missing account controls, weak permission explanations, and broken submission details. Both app stores enforce submission requirements that stop your listing if forms are incomplete or policies are violated.
Apple's hard rejection triggers
Missing or vague purpose strings for sensitive permissions can lead to App Store rejection. Writing "Required for app functionality" is not acceptable. Every camera, microphone, or location request needs a specific, user-facing explanation.
Other documented blockers:
- No in-app account deletion option (required since June 2022)
- Broken links, including a missing privacy policy or support URL
- Apps that crash on the current OS version
- Demo credentials required if your app has a login
These are straightforward checks worth handling before submission.
Apple has removed apps without EU trader status from the App Store in Europe until status is verified since February 2025.
Google Play's hard rejection triggers
An incomplete Data Safety section blocks submission. You must declare each type of personal data collected, whether third-party SDKs are used, and your data retention policy. SDK data collection still counts as your disclosure obligation.
Additional documented blockers:
- Missing privacy policy, required even if you collect nothing
- No data deletion option
- Runtime permissions requested before showing an in-app disclosure explaining the data use
If your disclosures do not match your app behavior, the submission can stop here.
Compliance deadlines that block submissions
Some release requirements turn older implementation choices into launch blockers. If you are shipping updates, check target API requirements, deprecated Android attestation APIs, and Apple receipt-validation changes before submission.
New apps and updates must target API level 35 or higher starting August 31, 2025. Apps still referencing SafetyNet will fail, since that API shut down in January 2025. Apps must support SHA-256 because Apple's SHA-1 certificate for receipt validation expired January 2025.
Store policy and release deadlines can block launch even after you fix the app itself, so handle these well before you submit.
A testing timeline you can actually follow
The easiest way to catch these issues is to test them in the same order you build and ship. The phases below turn the earlier risks and store rules into a sequence you can actually run.
The OWASP MASTG testing profiles define baseline security as a set of fundamental security requirements for mobile apps. The phases below turn that into a practical sequence.
Phase 1: during development
Start these on day one, not the week before launch.
- Secrets audit: Search your codebase for hardcoded passwords, API keys, and tokens. Use
grepor Snyk's free tier. Zero hardcoded credentials is the only passing score. - HTTPS verification: Run your backend domain through Qualys SSL Labs. Aim for a strong grade with modern TLS support.
- Data storage review: Confirm auth tokens live in iOS Keychain or Android Keystore. No sensitive data in SharedPreferences or device logs.
- Permissions minimization: Remove every permission your core functionality does not require. Add purpose strings for every remaining one.
- Authentication review: Remove the session token from a live request and confirm your server rejects it. Expired tokens should fail server-side.
This phase catches the mistakes that are cheapest to fix while you are still building.
Phase 2: pre-submission
Complete these shortly before you submit.
- Disable debug mode in your production build. Confirm android:debuggable="false" in the release manifest.
- Scan dependencies for known vulnerabilities using Snyk or npm audit. Fix any critical findings in authentication or cryptography libraries.
- Set up Play Integrity API for Android. SafetyNet was fully shut down in January 2025, and any remaining SafetyNet calls will fail.
- Verify app signing with your production certificate, not a debug certificate.
- Confirm target API level meets current Google Play requirements.
- Complete privacy disclosures in App Store Connect and Google Play Console. List every SDK's data collection.
Policy mistakes and release-build mistakes usually show up in this phase.
Phase 3: final validation
Run these checks right before submission.
- Automated static scan: Upload your final build to MobSF. Address every critical finding before generating the submission binary.
- Manual traffic inspection: Use Burp Suite Community Edition to intercept your app's actual network traffic. Confirm all communication is HTTPS with no sensitive data in plaintext.
This last pass helps you catch release issues before reviewers do.
Your platform handles infrastructure, not configuration
Secure hosting does not fix open database rules, weak permissions, or incomplete privacy forms. Platform support helps with infrastructure, but your security configuration still decides whether the app passes review.
Platforms vary in their infrastructure and security features, so teams should evaluate each vendor's security controls and compliance posture individually. Common failures, like open database defaults and missing privacy rules, come from configuration choices, not platform bugs.
Before you submit, run ImmuniWeb on your build, walk through the OWASP MAS Checklist, and complete both store privacy forms with every SDK listed. That combination can help catch common issues that lead to rejection or data exposure.
If you are building with the Anything AI app builder, you can focus on product decisions while the tool handles deployment infrastructure. The security configuration steps in this article still apply. Anything supports iOS deployment, while Android is still in development.
Run these checks before you ship. Your first submission has a much better chance of going through clean.
