What if anyone could create legitimate-looking short links on your domain without ever touching your servers?

Non-member? Click to read for free.

Back in 2022, I found multiple security issues in Google’s ecosystem and earned a spot in their Hall of Fame.🥇

This blog is about one of those. A fun little rabbit hole that started during a routine bug bounty session and ended with something that affected an entire platform.

If you’re into real-world security bugs, research writeups, and behind-the-scenes stories, follow me,

, on Medium to catch future posts.

It began while I was hunting bugs in a private HackerOne program. The Android app I was testing, let’s call it Redacted App, was using Firebase to generate Dynamic Links.

If you haven’t used them before, think of Dynamic Links as Google’s version of Bit.ly, a URL shortener that also handles deep linking in mobile apps. You’ve probably seen it in action if you’ve ever shared a location in Google Maps. Google Maps probably gave you a link which looked like:

https://maps.app.goo.gl/ZMf74qehY1gXM2ed8

Behind the scenes, this pretty link maps to a long URL like:

https://www.google.com/maps/place/Kailasa+Temple,+Ellora,+Maharashtra+431102/data=!4m2!3m1!1s0x3bdb925d7576f3e7:0xc53f42c5f6812405?utm_source=mstt_1&entry=gps&g_ep=CAESCTExLjYyLjYwMxgAIIgnKgBCAklO

This entire shortening is powered by Firebase Dynamic Links. You can use Google’s free subdomain and generate links like:

https://mydomain.page.link/abcd

Or even hook up your own custom domain with Google and generate links like:

https://mydomain.com/abcd

While intercepting network traffic from the Redacted Android app, I noticed something interesting.

The app was calling Firebase’s Dynamic Links API to generate short URLs on their domain. The request looked like this:

POST /v1/shortLinks?key=GOOGLE_API_KEY_HERE
Host: firebasedynamiclinks.googleapis.com
{
  "longLink":"https://redacted.com/profile/a9fg34f738gfv34f7",
  "domain":"https://redacted.com"
}

The response to this request is something like

{
  "shortLink":"https://redacted.com/a8Hh"
}

The first thing that came to my mind was, what if I change the long link to a domain I own? So I quickly changed longLink from “https://redacted.com/profile/a9fg34f738gfv34f7” to “https://attacker.com” and sent the request. To my surprise, I got a response with a short link which redirected the user to https://attacker.com 🤯

I had just created a perfectly legitimate-looking short link on redacted.com that redirected to my own server.

This wasn’t just a phishing vector. This was a full-blown brand impersonation factory.

My first instinct? I thought the Redacted app developers had simply misconfigured something, maybe shifted some logic to the client side by mistake.

But the more I dug into Firebase docs, the more shocked I got.

Turns out, Google officially recommends creating Dynamic Links from the client-side using a GOOGLE_API_KEY.

As some of you might know, a Google API Key is present in almost all the apps that use Firebase or other Google services in their app. The same key is used if you have used Crashlytics (a crash reporting service by Google) and a few other Google services in your application. This key is not considered a secret. At least, that’s what the official documentation says here.

“Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources”

“ … however, API keys for Firebase services are ok to include in code or checked-in config files.”

Yes. You read that right.

API keys, baked into apps, easily extractable, were enough to generate short links on any domain attached to a Firebase project.

No auth. No ownership verification. Just fire and forget.

I wasn’t convinced yet. Maybe there were checks I was missing.

So I quickly spun up a new Firebase project and added a new Android app to it. At this point, Firebase automatically created a Google API key for my project. As of now, I have not touched any settings of Dynamic links.

I tried to hit the Dynamic Links creation API shown previously with the Google API key that had just been created. I got a response saying

Your project (642******118) has not configured Dynamic Links.

Fair enough. I went to the Dynamic Links section, and I was presented with this page

I clicked the big friendly “Get Started” button and was presented with the following popup, where I entered a domain for my app

And that’s it. This automatically triggered the Google API key, which I had used previously in my app to be activated for Dynamic links, and now calling the same Dynamic links API created shortened links on mydomain.page.link domain.

If I had linked a domain like mydomain.com in the Firebase console, that would have created shortened links of mydomain.com

No confirmation. No email. No warning that the same API key I used earlier could now create links at will. 😬

This was getting interesting.

I wanted to see if Google’s own apps were vulnerable to this behaviour. So I picked one that I’d used before, Google Opinion Rewards.

Downloaded the APK, decompiled it, pulled out the Google API key, and hit the Dynamic Links endpoint for redirection to example.com.

And I got this back

https://googleopinionrewards.page.link/jofZ

Clicking it redirected to https://example.com/

I had just created a redirecting link from a Google-owned domain.

*You might see this not working now because they fixed it after my report. But you can still see that it is trying to redirect to example.com

I tried multiple other apps from Google, like Google Maps, and I was able to successfully generate short links on Google owned domains.

I reported this to Google through their Vulnerability Reward Program and was rewarded with $$$$.

Now to be fair, fixing this completely would require a massive shift, moving link creation logic to the server for potentially thousands of apps. That’s a breaking change that only a few companies would be willing to make.

So instead, Google added a mitigation.

After my report, on October 19, 2022, they emailed Firebase project owners asking them to configure Allowed Domains, a list of domains that the short links could redirect to.

If you’ve ever used Dynamic Links, you probably received an email that looked something like this:

The Firebase Dynamic links page now also displays this message

Now, if someone tries to create a short link that redirects to an unapproved domain, it gets blocked.

This change significantly reduced the abuse potential of Dynamic Links. A short link like https://yourdomain.com/abcd can no longer send someone to a malicious site, unless that site is on your allowlist.

This fix stopped arbitrary redirections, i.e. attackers can no longer create a link on your domain that redirects to theirs.

But can they still create links on your domain?

Yes. 😵

But why would anyone generate short links that point back to the same domain?

The answer? Metadata

Even without redirection, attackers can craft links that look legitimate in previews, with fake titles, thumbnails, and descriptions, but mislead users into trusting them.

And the worst part?
This is still unpatched. 🤯

Please let me know in the comments if you’d like a follow-up on how the metadata manipulation still works today, and how attackers can build links that look legitimate but mislead users. If enough people are interested, I’ll publish a deep dive into this second part.

This wasn’t just a theoretical risk. I demonstrated how attackers could generate misleading links on any verified domain using Firebase Dynamic Links. Links that looked trustworthy but weren’t. Google patched the redirection issue, but the metadata loophole still exists.

That means your domain could still be used to spread misinformation or phish your users, and you might not even know it’s happening.

Security is rarely about just one bug. It’s about the assumptions we make and how they can be twisted.

Curious what else I’ve uncovered? 🧠
From gaining root access to thousands of EVs and charging stations of a leading Indian automaker to hacking ISP management software used by over 350 providers, I hunt down vulnerabilities across all layers, from app to cloud, that carry serious consequences.

If this vulnerability caught your attention, you’ll definitely want to see what’s coming next. I’ll be sharing more blogs and write-ups as vendors roll out fixes for the other vulnerabilities I’ve reported.

If you found this valuable, a few claps can help spread the word and maybe nudge Google (and others) to tighten things up.

Got questions? Curious if your app could be affected? Drop a comment below. And if real-world bugs like this excite you, follow me,

, here on Medium. More are coming.

Thank you for your time :)