Does Apple check for hardcoded AWS credentials?

The reader I am writing for shipped an iOS app that talks to AWS, has an access key somewhere in the bundle, and wants to know whether Apple's review process will catch it. The short answer is no, and the longer answer explains why the gap exists, what independent research shows about how often AWS keys leak from production iOS apps, and what to do about it before your next submission.

Short answer

Apple App Review does not scan IPA binaries for hardcoded AWS credentials. The review pipeline focuses on policy guidelines (Guideline 5.1.1 on data collection, 2.5.1 on public APIs, 1.6 on data security) and does not run static analysis for AWS access key patterns like the AKIA prefix. Independent research from Ostorlab's mobile credential study found valid AWS secrets in roughly 1.8 percent of mobile apps it analyzed, and approved App Store apps regularly ship with AKIA or ASIA strings extractable through a basic strings command.

What you should know

• AWS access keys follow a documented prefix pattern. AKIA for long-lived IAM user keys, ASIA for short-lived STS session tokens, both followed by sixteen uppercase alphanumeric characters.
• Apple does not run secret scanners against your binary. The App Review pipeline is policy-focused and human-driven, not security-focused in the static-analysis sense.
• GitHub catches public source leaks; Apple does not catch compiled-binary leaks. A key that never went through GitHub but rides inside your Mach-O executable is invisible to both.
• The Uber breach started with an embedded AWS credential. The data exposure path is documented and the legal cost was 148 million dollars.
• The architectural fix is short-lived credentials. AWS recommends Cognito Identity Pools or STS AssumeRoleWithWebIdentity, not embedded IAM keys, per its IAM best practices guidance.

How does Apple's review actually inspect an IPA?

Apple's App Review combines an automated pre-screen with a human reviewer. The automated layer, per Apple's App Review section on developer.apple.com, runs checks for private API usage, missing entitlements, prohibited frameworks, and metadata violations. None of those involve running a credential regex over the Mach-O binary or the bundled frameworks.

The human reviewer installs the app on a device and walks through user flows. They check that the app does what its description says, that screenshots match, that purchases work, and that paid functionality routes through Apple's in-app purchase system where required. They do not decompile binaries, run otool, or scan strings for AKIA prefixes. That work happens at a security vendor, not at App Review.

Guideline 5.1.1 of the App Review Guidelines places responsibility for data security on developers. The wording assigns the obligation; it does not commit Apple to enforcing it through binary scanning. In practice, this means hardcoded AWS credentials can ride a build through review without anyone at Apple seeing them, and they regularly do.

How easy is it for an attacker to extract AWS keys from a shipped IPA?

Trivial. A decrypted IPA is a ZIP archive. A four-line shell pipeline finds the credentials:

unzip MyApp.ipa
cd Payload/MyApp.app
strings MyApp | grep -E 'AKIA[0-9A-Z]{16}|ASIA[0-9A-Z]{16}|aws_secret_access_key'
find Frameworks -name '*.dylib' -exec strings {} \; | grep -E 'AKIA|ASIA'

The Spaceraccoon writeup on hunting credentials in iOS apps walks through this approach against production App Store apps. The author found AWS keys, Firebase configs, and other credentials by extracting the IPA and grepping plaintext files plus the Mach-O binary.

Obfuscation does not change the result much. A key XOR'd against a constant, base64-encoded, or split across constants still gets reassembled at runtime. A dynamic instrumentation tool like Frida intercepts the AWS SDK's credential setter and reads the decoded value out of memory the moment the app uses it. The cost to an attacker is minutes, not days.

What does the research show about how often this happens?

Independent vendor analysis suggests embedded AWS credentials are common, not rare. The Ostorlab analysis of hardcoded secrets in mobile apps reported that out of 1,000 analyzed mobile applications, eighteen contained valid AWS secrets. Firebase credentials were more common (thirty-five per thousand) and Google Cloud Platform credentials sat at thirty-one per thousand. Approximately 1.8 percent of apps shipping AWS keys is enough to make it a structural problem, not an outlier mistake.

The Uber case from 2016 is the canonical real-world example. An Uber employee committed AWS credentials to a GitHub repository; attackers found the credentials, used them to access Amazon S3 buckets, and exfiltrated data on 57 million riders and drivers. Uber paid 148 million dollars in a 2018 settlement. The pattern is the same when the credentials come from a mobile binary instead of a public GitHub repo: an attacker who finds long-lived IAM keys gets whatever IAM policy that user has, often more than the developer realized.

AWS itself has responded by automating quarantine: when its scanners (or GitHub's secret scanning service) detect an exposed AWS key, AWS attaches the AWSCompromisedKeyQuarantineV3 policy that explicitly denies a list of dangerous IAM, EC2, Lambda, and Organizations actions. The quarantine is reactive and limits damage but does not undo data exfiltration that has already happened.

What should an iOS developer do before submitting a build with AWS dependencies?

The scanning Apple does not run has to happen on your side, alongside an architectural change. Three layers, in order of importance.

Layer 1: stop embedding long-lived credentials. AWS's recommended pattern for mobile apps is Cognito Identity Pools or STS AssumeRoleWithWebIdentity. Both work by exchanging a user authentication token (Cognito User Pool, Apple Sign In, your own backend JWT) for short-lived AWS credentials scoped to an IAM role. No AKIA key reaches the device. The role's IAM policy bounds what an attacker who steals the short-lived credentials can do. For server-side operations (cross-user processing, billing logic) the request goes through your backend, which holds its own credentials the client never sees.

Layer 2: scan every build before submission. Run a static analysis pass over the IPA looking for AKIA, ASIA, and aws_secret_access_key patterns, plus the equivalent patterns for Firebase, Stripe, Twilio, Mapbox, and any other SDK your app uses. The local pipeline shown earlier is a starting point. For builders who want an external automated read of their compiled build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused specifically on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps. The scanning runs against the IPA you would actually upload, so it catches anything that survived obfuscation or framework bundling.

Layer 3: rotate when you find something. If a scanner does find an AKIA key in a shipped build, treat it as compromised regardless of whether the app has been downloaded. Rotate the key, audit CloudTrail for unauthorized API calls under that key from the time it was first shipped, and check IAM Access Analyzer for the role's effective permissions. Replace the architecture with Pattern 1 before shipping the next build, not after.

What to watch out for

A common mistake is assuming that Apple's review acts as a backstop. It does not. The review process catches policy violations and obvious user-facing problems; it does not catch security issues hidden inside the binary. Treating App Review as part of your security pipeline is the wrong mental model.

A second mistake is trusting obfuscation. Splitting a key into chunks, encrypting it with a constant in the binary, or running it through base64 does not stop an attacker with Frida or with patience. The first time the app uses the credential, it appears in memory in plaintext. Apple does not check; attackers do.

A third mistake is conflating GitHub secret scanning with binary scanning. GitHub catches keys that pass through public repositories. It does not see what is inside the compiled IPA on App Store Connect. The two scanning layers are complementary, and the binary layer is the one most developers miss.

A fourth mistake is assuming Privacy Manifests close this gap. PrivacyInfo.xcprivacy documents Required Reason APIs (file timestamps, UserDefaults, system boot time, free disk space) and declared data types; it says nothing about embedded secrets. An app can have a clean Privacy Manifest, a compliant ATT prompt, and an AKIA key in its main binary, and Apple will still accept the submission.

Key takeaways

• Apple App Review does not scan IPA binaries for AWS access keys; treat the review process as a policy layer, not a security layer.
• Around 1.8 percent of mobile apps in the Ostorlab analysis carried valid AWS secrets; this is a structural issue, not a rare mistake.
• The architectural fix is short-lived credentials issued by Cognito Identity Pools or AWS STS AssumeRoleWithWebIdentity, not embedded IAM keys.
• Run a strings plus grep pass over your IPA before every submission; teams that want an external automated read aligned with OWASP MASVS often outsource that step to platforms like PTKD.com (https://ptkd.com).
• Rotate immediately when a key is found, audit CloudTrail for unauthorized use, and replace the architecture before the next build, not after.