Applebee's Shipped Its Database Password in an App. Could Yours Leak?

Applebee's left a customer database password inside its Android app, exposing names, birthdays and phone numbers. Here's how it happened and how to avoid it.

TheTechLane cover on a mustard-yellow dotted background with the TL logo in a large plum stamp circle, a tilted plum phone whose screen shows code with a masked password boxed in coral, a coral key sliding out of the phone, and the headline "Applebee's shipped its DB password. Could yours leak?"

Applebee's left a password for its customer database inside its own Android app, and anyone who pulled it out could read, and possibly change, customers' personal records. TechCrunch broke the story on October 30 after the restaurant chain confirmed the flaw was fixed.

Here's what you need to know:

  • A researcher found the hardcoded database credential in Applebee's Android app, which has more than a million downloads on Google Play.

  • The exposed records included names, emails, dates of birth, phone numbers, ZIP codes, veteran status and recent login IP addresses.

  • The researcher used AI to dig the credential out of thousands of lines of decompiled code.

  • Parent company Dine Brands says it has found no evidence of unauthorized access so far, but won't say whether it has the logs to prove it.

  • Applebee's won't say how many customers were affected. Its rewards program had at least 8.5 million members as of last year.

UML sequence diagram of the Applebee's app leak: a researcher downloads the Applebee's Android app from Google Play, decompiles the APK and uses AI code search to find a hardcoded database password, logs in to the customer database and sees names, emails, birthdays, phone numbers, ZIP codes and login IPs, with write access also possible; with no security contact, the researcher asks TechCrunch for help, TechCrunch verifies using a dummy account and reports the flaw, and Dine Brands says it is fixed with no evidence of unauthorized access so far

How one password in an APK opened a customer database

What Happened

UK-based researcher Robert Wiggins of What Security found the problem earlier in October, according to TechCrunch's report on the Applebee's database exposure. He used AI to search the source code of Applebee's Android app and found a password for an internal customer database sitting in plain sight.

Wiggins couldn't report it directly. TechCrunch says neither Applebee's nor Dine Brands had a way for researchers to report security issues, so he asked the outlet to help with disclosure.

TechCrunch then checked the claim the hard way. It downloaded and decompiled the app, confirmed the credential was there, created an Applebee's account with dummy data and watched Wiggins pull that record back out of the company's database. It held the story until the flaw was fixed, and Applebee's confirmed on Thursday, October 29, that it had acted to block unauthorized access.

The database held customer names, email addresses (and whether they were verified), dates of birth, phone numbers, ZIP codes, veteran status, login counts, account creation dates and the IP addresses of recent logins. Wiggins also said the credential could have let an attacker modify customer data, not just read it.

As Privacy Affairs notes in its breakdown of the leak, passwords and payment card details weren't among the data TechCrunch listed.

A Dine Brands spokesperson told TechCrunch: "Our security team promptly launched an investigation and has not currently found any evidence of unauthorized access." When asked, the spokesperson wouldn't say whether the company has server logs it could check, or any logs at all. "Our investigation is ongoing, and we will take appropriate steps based on our findings," the company added.

Why It Matters

Hardcoding credentials is one of the oldest mistakes in the book. MITRE's CWE-798 entry on hard-coded credentials warns that client-side apps with built-in passwords are especially risky, "since the extraction of a password from a binary is usually very simple." Every copy of the app carries the same key.

That's what makes this one sting. The app wasn't hacked. As a DEV Community write-up on the Applebee's flaw puts it, the credential "was not stolen, phished, or guessed." It shipped inside a public app with over a million installs.

The AI angle cuts both ways. Wiggins used a model to find a needle in thousands of lines of code. Attackers can do the same thing at scale, across every app in a store. Secrets that once sat unnoticed in a decompiled APK are now much cheaper to find.

And "no evidence of unauthorized access" only means something if you have logs to look at. Dine Brands wouldn't say whether it does, and Business Bearings points out that nobody knows yet how many customers were affected.

We've seen the same pattern with AI tools: when OpenCode's console breach exposed users' AI API keys, the damage came from secrets stored where attackers could reach them.

What It Means for Developers

If your mobile, desktop or single-page app ships with a secret in it, assume it's public. Obfuscation slows people down; it doesn't stop them.

Architecture flowchart comparing two designs: before, a mobile app carries a database password in its code and logs straight in to the customer database with full read and write access, so anyone with the APK can decompile it and reuse the login; safer, the app holds no secrets, the user signs in to an auth service that returns a short-lived per-user token, the app calls your own scoped, rate-limited and logged API with that token, and only the API holds the database credential on the server

Where the database secret should live instead

What to do this week:

  • Grep your release builds, not just your repo. Decompile your own APK or IPA, or unpack your JS bundle, and search for connection strings, password=, API keys and private keys.

  • Never let a client talk to a database directly. Put an authenticated API in front of it, and give the client a short-lived, per-user token instead of a shared credential.

  • Scope what any shipped key can do. CWE-798 recommends limiting back-end credentials "to only performing actions valid for the front end." Read-only, row-level, rate-limited.

  • Add secret scanning to CI. Block builds that contain credential patterns, and scan the final artifact as well as the source.

  • Rotate anything that ever shipped. Removing a secret from the next release doesn't help the millions of copies already installed. Rotate it on the server side.

  • Log database access and keep the logs. If someone reports a leak, you need to be able to answer "did anyone use it?"

  • Publish a way to report bugs. A security.txt file or a security@ inbox would have let Wiggins reach Applebee's directly.

If you build web apps, the same rule applies to keys in front-end bundles. Platform-level secret storage, like the WordPress 7.2 Secrets API for encrypted API keys, keeps credentials on the server where they belong.

What's Next

Dine Brands says its investigation is ongoing. The big open questions: how long the password sat in the app, how many customers were in the reachable database, whether the company has logs that can rule out misuse, and whether it'll notify customers or regulators. Privacy Affairs says the company didn't respond on how long the password was exposed or on notification plans.

Watch for a formal breach notice if the investigation finds access. And expect more stories like this: if one researcher with an AI model can find a credential buried in an app with over a million downloads, so can anyone scanning app stores for them.

FAQ

Was my Applebee's payment card exposed?

Card details weren't among the data TechCrunch listed. The exposed fields were personal details like name, email, date of birth, phone number, ZIP code, veteran status and recent login IP addresses.

Did hackers actually access the data?

Dine Brands says it hasn't found any evidence of unauthorized access so far. It wouldn't tell TechCrunch whether it has the server logs needed to confirm that, so the answer isn't settled.

How do I keep secrets out of my own app?

Keep credentials on the server, give clients short-lived per-user tokens through an API, and scan both your source and your final build artifacts for secrets before release. Rotate anything that has ever shipped.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.