Applebee's App Hardcoded a Database Password: Check Yours

Applebee's Android app had a hardcoded database password that gave access to the company's customer database, TechCrunch reported. The app has more than a million downloads on Google Play. Anyone who decompiled it could read customer records and, per TechCrunch, possibly change them. The worst part: the researcher who found it had no way to tell Applebee's.

What actually happened

Robert Wiggins, a U.K.-based researcher at What Security, found the credential earlier this month. He used AI to search thousands of lines of the app's source code. TechCrunch decompiled the app itself and confirmed the access with a test account.

The exposed fields included customer names, email addresses, dates of birth, phone numbers, ZIP codes, veteran status, login counts, account creation dates, and the IP address of the most recent login. Applebee's had at least 8.5 million rewards members as of last year. The company would not say how many records were exposed or how long the password was in the app.

Applebee's confirmed on Thursday that it had fixed the issue. A Dine Brands spokesperson said the security team "has not currently found any evidence of unauthorized access," but would not say whether it has logs that could prove that. TechCrunch notes that neither Applebee's nor Dine Brands had a way to report security issues, so Wiggins asked the press for help.

Why a hardcoded database password matters for your business

Your mobile app is a file anyone can download and open. Every string in it is public. That includes API keys, database URLs, and passwords, whether you minify the code or not. And the cost to find them is going down: Wiggins used AI to read the code. Attackers do the same.

If you have a branded app, a loyalty program, or an ordering app built by a contractor, check it this week:

• No database credentials in the client. Ever. The app talks to your API; your API talks to the database. Keys that must ship in the app (Firebase, Supabase anon keys) need row-level security rules that assume the key is public.
• Scan the build, not only the repo. Run a secret scanner (gitleaks, trufflehog) on the source, and decompile your own APK once to see what an attacker sees.
• Publish a way to report bugs. A /.well-known/security.txt file with an email address costs nothing. Without it, your bug report goes to a reporter instead of to you.
• Keep access logs. "We found no evidence" is only worth something if you have logs to look in.

Sources: TechCrunch.