Upload screening and a security scan are different jobs
· 7 min read
When people ask whether a test build is "scanned", they usually mean one of two very different things. One is screening that a sharing service runs on every upload, to keep abusive apps off its links and protect the people who tap them. The other is a security scan of your own build, which tells you, the developer, what you left in it. Both are useful. They answer different questions, they are run by different people for different reasons, and one does not replace the other.
Job one: upload screening by the service
A service that turns any uploaded file into a public install link is an easy target for abuse: fake banking apps, stolen paid apps, spyware sent to a partner's phone. Screening is how a service tries to keep that off its links. Common parts, across the services that describe theirs:
- Removed file hashes. When staff take a build down, the service keeps a hash of the file and refuses the same file later.
- App ID blocklists. Bundle IDs and package names that should never appear, such as big brand apps and IDs tied to known abuse.
- Permission based holds. An Android build that asks for a set of permissions typical of covert surveillance is held or refused.
- Antivirus engines. Some services run uploads through an antivirus engine, either before the link goes out or in the background afterwards.
- Reports. A report button on the install page, with a person who reviews what comes in.
Who it protects: testers and the service. It says nothing useful about the quality of an honest developer's app. A clean result means the file did not match anything the screen looks for, not that the app is safe. No screen catches everything.
Job two: a security scan of your own build
A security scan reads your .ipa or .apk the way an attacker with a free tool would, and lists what you would rather fix before the build leaves the team:
- Secrets left in the code or resources: cloud keys, payment keys, private keys, tokens.
- Settings: Android backups without rules, exported components, plain HTTP, trusted user certificates, debuggable builds; on iOS, App Transport Security turned off and debug entitlements in the wrong build.
- Library versions with public advisories.
- A mapping of each finding to the OWASP MASVS categories, so you know which area it belongs to.
Who it helps: the developer. It assumes the app is yours and honest, and it looks for your mistakes. It does not look for malicious intent. Our guide to security checks before you share a build walks through the list by hand, and a security scan vs MAST tools explains where a quick scan stops and a full test starts.
| Upload screening | Security scan of your build | |
|---|---|---|
| Run by | The sharing service | You, or a tool you choose |
| Protects | Testers and the service | Your app and its users |
| Looks for | Abuse: known malware, removed files, blocked IDs, surveillance permissions | Mistakes: secrets, weak settings, old libraries |
| Result | Upload accepted, held or refused | Findings with how to fix them |
| What it does not tell you | Whether your app is well built | Whether an app from someone else is honest |
What AppForShare does, and does not do
AppForShare does both. This is what it does on the screening side, on every plan, guest uploads included:
- A check for known malware. Right after the link is issued, ClamAV opens every uploaded .apk or .ipa and checks the files inside, and the file's SHA-256 is looked up at MalwareBazaar by abuse.ch (only the hash leaves our servers). A match holds the build for a person to review, and live builds under 72 hours old are checked again daily with new signatures. See the malware check.
- The same file twice. When our staff remove a build for abuse, we keep the SHA-256 of its file with the reason and the date. An upload of the same file is refused.
- An app ID blocklist. Uploads whose app ID belongs to a big company that never ships test builds here are refused, and known malware app IDs too. This is a check of the ID, not of the code.
- A permission hold for guest Android uploads. An Android upload made without an account whose permissions sit at the covert surveillance end (for example reading SMS and the call log plus an accessibility service) is held. The link exists but takes no installs until a person releases or removes it. Account uploads and iOS builds are not screened this way.
- Reports need a reason. "Report this app" on the install page asks for a category and a short description. An automated review helps our team sort reports; a person decides. The AI never removes or releases anything.
- A hold rule by plan. On guest and Free builds, a report that looks real or unclear holds the build and the owner gets an email with the reason. On Pro and Team, the owner gets a warning and the build keeps working until five different people report it; then it is held for review.
More detail is on how reports work.
On the developer side, every account build gets our Security scan at upload. It reads the file and never runs the app. Free shows the counts; Pro and Team show every finding with where it is and how to fix it; Team adds the full report grouped by MASVS category and the history across builds. It is MASVS mapped checks, not a penetration test and not a certification.
For testers: before you install from a link
Whatever a service screens, the person who taps install makes the last call. A short routine:
- Know the sender. Install builds only from people or companies you work with, sent through a channel you already trust. A link from a stranger, a forum or an ad is a different thing.
- Read the install page. Check the app name, the version and who shared it. If the name does not match what you were told, stop and ask.
- Read the permissions. On Android, a test build for a shopping app has no reason to read your SMS or ask for an accessibility service or device administrator. Our guide to Android permissions in plain English says what each one allows.
- Be careful with profiles on iPhone. A configuration profile that only reads your UDID is normal for ad hoc testing. A profile that asks to manage the device, or a request to trust an enterprise developer you have never heard of, is not.
- Use a test device if you can. Keep work accounts and banking apps off the phone you test on, and remove the build when the test round ends.
- Report what looks wrong. Use the report button on the install page and say why. A reason helps the person who reviews it.
For developers: what to run on your own build
Before a build goes to a client, check it the way an outsider would. Run a security scan and fix anything marked to fix, especially secrets. If you use the AppForShare CLI, npx appforshare check ./app.apk runs the readiness and install checks on your computer with nothing uploaded, and with a Pro or Team token it prints the security findings too. In CI, appforshare security <build> --fail-on block stops the pipeline when a finding needs fixing. Then share the build with a password or to named testers if it is not meant for everyone.
Common questions
Does AppForShare check uploads for malware?
Yes. Every upload, on every plan, is checked for known malware with ClamAV and a MalwareBazaar hash lookup, and a match is held for a person to review. It also refuses files staff removed for abuse and blocked app IDs, holds guest Android uploads with a surveillance style permission set for a person to review, and acts on reports with a reason.
If a service screens uploads, is every build on it safe?
No. Screening lowers the chance of abuse; it does not prove an app is honest or well built. Testers should still check who sent the link and what the app asks for.
Does a security scan find malicious apps?
It is not built for that. It looks for a developer's own mistakes, such as hardcoded keys and weak settings, in a build the developer trusts.
Who decides when a build is reported on AppForShare?
A person on our team. An automated review helps sort reports, but it never removes or releases a build.
If you want both halves on your next build, the Security scan for you and a report process for your testers, you can make a free AppForShare account and upload it.
