Security Analysis of the Official White House iOS App

On March 27, 2026, the White House released its official iOS app. Published by the Executive Office of the President under the bundle ID gov.whitehouse.app, it promises citizens “direct, unfiltered access to the People’s House.”

So we took them up on it. We downloaded the app, unzipped it, and took a look at what’s inside. No hacking, no traffic interception, no DRM bypassing. Just standard macOS tools (strings, nm, plutil) pointed at a free app anyone can download from the App Store.

What we found made us do a double-take. Then a triple-take. Then we made coffee and kept going.

The Basics

Bundle ID gov.whitehouse.app
Version 47.0.0 (build 68)
Seller Executive Office of the President
Framework React Native (Expo) with Hermes engine
Size ~40 MB
Built with Xcode 26.0, iOS SDK 26.0
Build environment Expo Cloud Build (/Users/expo/...)

The app is a React Native application built with Expo and compiled with Hermes bytecode. It has five tabs (Home, News, Live, Social, and Explore) and pulls content from a WordPress REST API at whitehouse.gov. So far, so normal. A government news app built by a contractor on a standard stack. Nothing to write home about.

Then we looked at the frameworks.

Finding 1: A Russian-Origin Company Executes Live JavaScript Inside the App

The Social tab loads an Elfsight widget inside a WebView:

<script src="https://elfsightcdn.com/platform.js" async></script>
<div class="elfsight-app-4a00611b-befa-466e-bab2-6e824a0a98a9"
     data-elfsight-app-lazy></div>

Elfsight is a widget company originally founded in Tula, Russia. It has since redomiciled to Andorra, with prior business listings in Armenia. Its platform.js script is loaded at runtime from Elfsight’s CDN, meaning the code can change at any time without an app update or App Store review.

We’ll say that again: a .gov app is loading live, modifiable JavaScript from a company that started in Russia.

The WebView has a ReactNativeWebView.postMessage() bridge to the native layer. Elfsight’s own privacy policy states it collects IP addresses, sets tracking cookies (including session tokens and click tracking stored up to a year), and sends data to core.service.elfsight.com.

If Elfsight’s CDN were compromised, or if the company were compelled to modify the script, arbitrary JavaScript would execute inside the official White House app on every user’s device.

An official U.S. government application should not execute runtime JavaScript from a foreign commercial entity.

Finding 2: GPS Tracking With No Feature Justification

Most news apps need to know what you want to read. This one wants to know where you are while you read it.

The app ships with 10 separate OneSignal frameworks totaling ~2.4 MB, including OneSignalLocation.framework (104 KB). Symbol analysis of this framework reveals a complete location tracking pipeline:

+[OneSignalLocationManager sendLocation]
+[OneSignalLocationManager requestLocation]
+[OneSignalLocationManager resetSendTimer]
+[OneSignalLocationManager beginTask]
+[OneSignalLocationManager startLocationSharedWithFlag:]
-[OneSignalLocationManager locationManager:didUpdateLocations:]

The app also declares NSLocationAlwaysAndWhenInUseUsageDescription in its Info.plist, requesting permission to track location even when the app is in the background.

There is no map, no local news, no geofencing, no “events near you,” no weather. Nothing in the app that requires location. The sendLocation method is designed to transmit GPS coordinates to OneSignal’s servers on a timed interval (foregroundSendLocationWaitTime). Whether this code path is actively enabled at runtime would require network traffic analysis, but the capability is compiled into the app and the always-on location permission is requested.

OneSignal is a private, VC-backed company (SignalFire, Y Combinator, HubSpot Ventures, ServiceNow) headquartered in San Mateo, CA, with data stored on Google Cloud.

Finding 3: The Privacy Manifest Is Provably False

Apple requires apps to be upfront about what data they collect, through a privacy manifest (PrivacyInfo.xcprivacy). Think of it like a nutrition label, but for your data. Here’s what the White House app puts on the label:

NSPrivacyCollectedDataTypes: []    ← empty array
NSPrivacyTracking: false

“Nothing to see here, folks. We collect absolutely nothing.”

Here is what the app actually contains, verified through binary and framework analysis:

Data Type Evidence
GPS coordinates OneSignalLocationManager.sendLocation, setLocationWithLatitude:longitude:
Device identifiers OneSignal push tokens, pushSubscriptionId, externalId
Behavioral analytics OSRequestSendOutcomesV2, OSRequestOnFocus (sends activeTime, netType, deviceType, influenceParams)
Notification engagement OSRequestSubmitNotificationOpened, OSRequestInAppMessageViewed/Clicked
Session data OSSessionManager, OSRequestSendSessionEndOutcomes
User identity OSRequestCreateUser, OSRequestIdentifyUser, OSRequestAddAliases
PII via contact form handleContactForm with email, phone, street address fields
Email via newsletter Mailchimp subscription at whitehouse.us10.list-manage.com

That’s like putting “0 calories” on the label of a cheeseburger. While shipping ten different analytics frameworks. With GPS tracking. This is a violation of Apple’s App Store Review Guidelines Section 5.1.2.

Symbol analysis of OneSignalCore.framework reveals an OSRemoteParamController that accepts server-side configuration:

-[OSRemoteParamController saveRemoteParams:]
-[OSRemoteParamController saveLocationShared:]
-[OSRemoteParamController savePrivacyConsentRequired:]
-[OSRemoteParamController hasLocationKey]
-[OSRemoteParamController hasPrivacyConsentKey]

These are standard OneSignal SDK features, but the implication is significant: OneSignal’s servers can remotely enable or disable GPS tracking and change whether privacy consent is required, all without an app update, without Apple review, without the user knowing. It’s a light switch for location tracking, and it’s not in the White House’s hands.

The app injects JavaScript into WebViews that forcibly removes cookie consent banners, GDPR notices, and login walls from embedded third-party content:

(function() {
  var css = document.createElement('style');
  css.textContent = [
    '[class*="cookie"], [id*="cookie"]',
    '[class*="consent"], [id*="consent"]',
    '[class*="gdpr"], [id*="gdpr"]',
    '[class*="onetrust"], [id*="onetrust"]',
    '[class*="login-wall"], [class*="loginWall"]',
    '[class*="signup-wall"], [class*="signupWall"]',
    '[class*="upsell"], [class*="Upsell"]',
  ].join(',') + '{ display: none !important; }';
  document.head.appendChild(css);

  var observer = new MutationObserver(function() {
    var els = document.querySelectorAll(
      '[class*="cookie" i], [class*="consent" i], [class*="gdpr" i]'
    );
    els.forEach(function(el) { el.style.display = 'none'; });
  });
  observer.observe(document.body, { childList: true, subtree: true });
})();

The code specifically targets OneTrust and CookieConsent by name and uses a MutationObserver to continuously monitor for and hide consent elements as they appear.

To put it plainly: when a website asks “Do you consent to cookies?” this app answers “You don’t get to ask,” on behalf of the user, silently. An official government app is programmatically circumventing legally-mandated privacy consent mechanisms on third-party websites.

Finding 6: Minimal Security Hardening

We’ve audited apps for startups with three employees that had better security than this. For an app published by the Executive Office of the President, the security posture is… well, see for yourself:

Security Control Status
Certificate pinning None (the app includes a JS-level domain whitelist and a secureFetch wrapper, but no TLS-level certificate or public key pinning. No SHA-256 pin hashes exist in the bundle.)
Jailbreak detection None
Anti-tampering None
Anti-debugging None
Code obfuscation None (Hermes bytecode only)
App attestation None
Runtime integrity checks None

We searched the entire binary and JS bundle for any evidence of TrustKit, SSLPinning, certificate pinning, jailbreak detection strings (Cydia, MobileSubstrate, frida), or anti-tamper mechanisms. Nothing.

The app does include a secureFetch wrapper and a variable named SSL_PINNING_CONFIG, but these are misleading. We decompiled the Hermes bytecode and found the actual implementation:

// Decompiled from Hermes bytecode - Metro module 1458
Object.defineProperty(exports, "REQUIRE_HTTPS", obj2);
Object.defineProperty(exports, "isSecureApiUrl", obj3);
Object.defineProperty(exports, "secureFetch", obj5);
Object.defineProperty(exports, "SSL_PINNING_CONFIG", obj6);

// The "pinning" is a domain whitelist:
envSlot_1 = [
  "whitehouse.gov",
  "api.onesignal.com",
  "exp.host",
  "youtube.com",
  "googleapis.com"
];

// isSecureApiUrl checks hostname.endsWith(domain)
// getSecurityHeaders returns { "User-Agent": "WHGov-Mobile/1.0" }

The implementation is a JavaScript-level domain whitelist that checks if a URL’s hostname endsWith an allowed domain. There are no SHA-256 certificate hashes, no .cer or .pem files, and no TLS-level pinning of any kind. The SocketRocket WebSocket library (SRPinningSecurityPolicy) ships with React Native and supports pinning, but the main binary never references it. It’s dead code.

Worse, the domain whitelist itself is bypassable. The endsWith check has no dot-boundary validation, which means an attacker who registers evilwhitehouse.gov or fakeyoutube.com passes the check. The correct implementation would verify hostname === domain || hostname.endsWith('.' + domain). As written, this security control can be defeated with a $12 domain registration.

Anyone on the same WiFi network (say, at a coffee shop, an airport, or a congressional hearing room) can intercept API traffic with a proxy. Anyone with a jailbroken device can hook and modify the app’s behavior at runtime. The app relies entirely on iOS’s built-in App Transport Security for HTTPS, which is bypassed trivially with a custom root certificate.

Finding 7: Dormant Over-the-Air Code Push

The Expo Updates infrastructure is fully configured but currently disabled:

EXUpdatesEnabled: false
EXUpdatesCheckOnLaunch: NEVER
EXUpdatesURL: https://u.expo.dev/1590bd5c-74a2-4dd4-8fe6-ff5552ca15b6
EXUpdatesRuntimeVersion: 47.0.0
expo-channel-name: production

Expo OTA is a standard feature used by thousands of apps, but the security implications for a government app are different. Here’s the scenario: whoever controls the Expo project account (1590bd5c-74a2-4dd4-8fe6-ff5552ca15b6) submits a native update framed as a minor bug fix that flips EXUpdatesEnabled to true. Apple approves it because nothing looks suspicious. From that point forward, arbitrary JavaScript can be pushed to every installed copy of the app without App Store review. The reloadAsync function is already in the bundle, ready to go. For a standard consumer app this is normal. For an app carrying the seal of the presidency, this is a remote code deployment pipeline that bypasses the only independent review gate (Apple) between the developer and millions of devices.

Finding 8: Full Behavioral Intelligence Pipeline

OneSignal isn’t just sending push notifications. The OneSignal SDK includes 24+ server request types that implement a complete behavioral intelligence system. These are standard SDK capabilities, but they are compiled into and available to this app:

  • OSRequestOnFocus reports activeTime, netType, deviceType, and influenceParams (how long the user spent, on what network, influenced by which notifications)
  • OSRequestSendOutcomesV2 measures behavioral outcomes tied to notification campaigns
  • OSRequestSendSessionEndOutcomes reports session duration and influence attribution at session end
  • OSSessionManager and OSChannelTracker track direct vs. indirect vs. unattributed notification influence with configurable attribution windows
  • OSRequestInAppMessageViewed/Clicked/PageViewed tracks engagement with targeted in-app messages
  • OSRequestCustomEvents sends custom behavioral events

This is a marketing attribution system, the kind you’d expect from a DTC brand selling mattresses, not the Executive Office of the President. It measures whether government push notifications change user behavior: which messages drive engagement, which fall flat, and how long the influence lasts.

Complete Data Flow

Every interaction with the app generates data that flows through commercial third-party infrastructure:

Destination Data Company
OneSignal (San Mateo, CA / Google Cloud) GPS (capability compiled in), device fingerprint, sessions, behavioral outcomes, notification engagement, user identity OneSignal, Inc. (VC-backed)
Elfsight (Andorra, originally Russia) IP address, session tokens, click tracking, widget views Elfsight, SL
Mailchimp (Atlanta, GA) Email address, postal code Intuit
YouTube / Google Video playback data Alphabet
Facebook / Meta Page plugin iframe data Meta
Uploadcare (Vancouver, BC / AWS) Image request logs Tiugo Technologies
whitehouse.gov Contact form PII, content API requests U.S. Government

None of the commercial services appear to be FedRAMP authorized. Your data’s road trip looks less like a secure government pipeline and more like a startup’s Series A tech stack.

Recommendations

If the White House wanted to address these issues:

  1. Remove Elfsight and self-host the social feed widget
  2. Remove OneSignalLocation.framework, delete the framework and remove all location permission strings from Info.plist
  3. Fix the privacy manifest to accurately declare all data collection
  4. Implement certificate pinning to prevent MITM interception of API traffic
  5. Remove the consent banner stripping code
  6. Add security hardening: jailbreak detection, anti-tamper, runtime integrity checks
  7. Audit OneSignal’s remote parameter surface, or move to self-hosted push infrastructure
  8. Remove or fully disable Expo OTA configuration

None of these are difficult. A competent iOS team could address all of them in a sprint. Most of these issues would have been caught by a standard security review before publishing to the App Store. We’d be happy to help. Our rates are very reasonable and we accept purchase orders from the federal government.

Methodology

We saw the announcement on X and wondered what was inside. A few hours later with some rudimentary tools and here we are:

  • Download: ipatool (authenticates with Apple ID to download the IPA from the App Store)
  • Extraction: Standard unzip of the IPA
  • Binary analysis: nm, otool, strings, codesign
  • JS bundle analysis: String extraction from Hermes v96 bytecode
  • Framework analysis: Symbol dumps of all 13 embedded frameworks
  • Config analysis: plutil on all plist files, entitlements extraction

No servers were probed. No network traffic was intercepted. No DRM was bypassed. No tools were used that require jailbreaking. Everything described here is observable by anyone who downloads the app from the App Store and has a terminal. If your adversaries haven’t already done this analysis, they’re having a slow week.

Disclosure

These findings were published on the day the app was released (March 27, 2026). We have not received a response from the White House or CISA at the time of publication. If the developers would like to discuss these findings or need assistance addressing them, they can reach us through our contact page.

About

Atomic Computer provides cybersecurity, infrastructure, and development services. Over twenty years of experience building and securing systems, from startups to platforms like Etsy. If you need a security assessment of your mobile app, infrastructure, or development pipeline, get in touch.

And if you’re the staffer who vibe coded this app, seriously, call us. We can help.

Have a question about this, or a project you're working on?

Schedule a call Contact us