What if an attacker could publish a link on your domain and you had no way to revoke it, leaving it live forever for phishing, scams, or brand abuse?

Non-member? Click to read for free.

In my previous blog, Your Domain, My Playground: How I Created Links on Your Site Without Permission, I revealed how attackers could generate shortened URLs on any Firebase-connected domain. This allowed them to create links that looked legitimate but redirected users to attacker-controlled sites, all without touching the domain owner’s servers.

Following that disclosure, Google introduced an important mitigation by strongly encouraging project owners to configure an “Allowed Domains” list, prominently highlighting it in the Firebase console, sending reminder emails, and urging adoption to limit which domains shortened links can redirect to. While not mandatory, this significantly helped reduce attackers’ ability to arbitrarily redirect users to malicious external sites.

But does that mean the problem is solved? Unfortunately… no. It’s like locking the front door while leaving the windows wide open.

What Exactly Are Firebase Dynamic Links?

Firebase Dynamic Links (FDL) are more than just URL shorteners. They’re designed to provide a seamless experience when sharing links that open in mobile apps or websites, with support for “deep linking” directly into specific app content.

Beyond simply redirecting URLs, FDL allows developers to attach metadata to each link. This metadata can include:

• A title (headline shown in link previews)
• A description (summary text)
• A thumbnail image (preview picture)

This metadata is what you see when a link is shared in messaging apps, social media feeds, or browsers. It makes links more attractive, informative, and trustworthy to users.

The Dark Side of Link Metadata

Even with an Allowed Domains list in place, I could still create links on your domain that point to any site within that list. At first, that might not sound dangerous. After all, it’s an approved destination. But what if I could make that link preview look like something completely different?

Here’s where it gets interesting. If I can create short links on your domain (thanks to it being on your Allowed Domains list) and set my own metadata, I can make that link look like anything I want, even if the actual destination is completely safe and hosted by you.

Imagine you get a link in WhatsApp, LinkedIn, or Slack that looks like this:

• The title says: “Independence Day Offer — Book today & Get Full Refund”
• The description reads: “Only for today. Explore breathtaking Switzerland at Zero Cost. First 100 customers only”
• The thumbnail: A stunning picture of the Swiss Alps with the MakeMyTrip logo placed in the corner, just like an official promo banner.
• The URL shows your domain: makemytrip.com

Note: MakeMyTrip is just a stand-in for this demonstration. In reality, they don’t use Firebase Dynamic Links and weren’t vulnerable. The example is only to help you visualise how this could play out.

Everything checks out. The link? Not some random xyz.com. It’s makemytrip.com. Looks safe enough… right?

You click it and, just as promised, it takes you to the real MakeMyTrip website, even opens the app if installed. It all looks legitimate. The Switzerland package is right there.

You pay lakhs for the dream holiday, confident you’ll get the full refund as advertised. You wait a day, a week… nothing. Finally, you call customer support, only to hear the chilling words:

“Sir, we don’t have any such offer. That link didn’t come from us.”

The payment went directly to MakeMyTrip, but the false promise in the preview was enough to trick you into making the purchase.

And it’s not just about fake travel deals. The same trick works on other major platforms too, even Google’s own apps that use Dynamic Links, like Google Maps.

I created a link that opens the Google Maps Timeline app on Android with a customised title and image. This is a real example generated on the Google Maps domain.

Imagine the damage. Not just fake offers, but scathing headlines or fabricated news plastered right under the company’s own domain. One click, and the brand’s trust can crumble, even though the site itself is doing nothing wrong. The attacker controls the story. The company only finds out once the reputational fire has already started burning.

So, how would I even know if someone is misusing my domain?

You might think, “Well, I can just check my Firebase Dynamic Links dashboard. If someone’s creating shady links on my domain (or maybe even did so in the past before I set up allowed domains), I’ll see them there, right?”

Wrong.

The Dynamic Links console only shows links that you create from the console itself. Any links generated through the API, which is exactly how an attacker would do it, never show up there.

In other words, you could have dozens of malicious links floating around on your verified domain, and you’d have no clue unless you stumble upon them by accident.

Here is a screenshot of my console where I have created 2 links using the console and 4 more using API, but only 2 are shown on the console.

Even if you discover them through user reports or external monitoring, there is currently no way to revoke or delete these links.

So, in the MakeMyTrip example we discussed earlier, the malicious link generated by the attacker can’t simply be revoked. Since it wasn’t created from your console, you have no visibility of it and no control over deleting or disabling it.

This lack of visibility and control amplifies the risk of metadata abuse on your domain.

What Does This Mean for Domain Owners?

If you’re using Firebase Dynamic Links with a custom domain or subdomain:

• Regularly check your allowed domains list to minimise redirection targets.
• Educate your users and teams about phishing risks, even from seemingly legitimate links.
• Monitor social media and other channels for suspicious links claiming to be from your domain.
• Reach out to Google Firebase support for updates on this metadata abuse issue.

Conclusion: The Problem Isn’t Fully Fixed Yet

While Google fixed the biggest risk of arbitrary redirection, the metadata manipulation vulnerability remains unpatched, allowing attackers to exploit trusted domains for deception.

This issue underscores an important lesson in security. Patches often address the most obvious threats, but subtle abuse vectors can persist for much longer.

Curious what else I’ve uncovered? 🧠

From hacking EVs and charging stations to exploiting ISP tools used by hundreds of providers, I hunt for vulnerabilities with real-world consequences.

If this vulnerability caught your attention, you’ll definitely want to stick around. I’ll be sharing more blogs and write-ups as vendors roll out fixes for other high-impact bugs I’ve reported.

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

Got questions? Wondering if your app could be at risk? Drop a comment below. And if real-world security flaws excite you, follow me,

, here on Medium. More is on the way.

Thanks for reading :)