Only 8 links had been created on AnchorURL before one of them was misused to link to malicious content. AnchorURL is a site I created last year to solve a simple problem: creating permanent links that could be changed to point to a different location over time. This was particularly useful for linking to a SharePoint site, where I had noticed the link kept changing slightly over time. Additionally, I wanted to be able to share edit access to the link, such that a group could own it and edit it over time as the destination changed its link. I wrote all of this down in the blog post I made when the project was created.
I anticipated that someone might try to misuse the site at some point, but I thought more actual users would join before that became an issue. I did not expect that only 8 links would be created before one of them was flagged. This blog post goes through how I found out, what I did to resolve it, and how I am preventing it going forward.
What happens when your site gets flagged?
The discovery was mostly luck. An unrelated health check failure happened to send me to the site, and when I went to verify it was still up, I was met with the warning page myself. The flag itself would never have tripped a health check, since it only affects browsers, not the server. Google also has no way of notifying you unless you have verified ownership of your domain, so the site could easily have sat flagged for a long time without me knowing. Now that ownership is claimed, Google will automatically send me an email if it happens again.
Google flags your site if it hosts or redirects to malicious content. There are different kinds of malicious content, but the specific threat AnchorURL was hit with was phishing. Someone had created a link with a real-looking name, “/secure-mail”, and pointed it at a phishing site posing as a mail service. That target site was already flagged by Google, and the malicious user was presumably placing it on anchorurl.com to make the link look trustworthy. The AnchorURL link certainly looked a lot less suspicious than the target did.
Because the site redirected to malicious content, the entire AnchorURL domain was flagged. The flag goes into Google Safe Browsing, which is used not only by Chrome but also by Firefox, Safari, and Android, so effectively every visitor was met with a full-page red warning declaring it a “Dangerous site”. You could still press “Details” and “Visit this unsafe site”, but the page did everything it could to turn visitors away.
Resolving the issue
The warning page also linked to instructions for resolving the issue. Specifically, Google Search Console can show you exactly what malicious content was found on your domain. In order to access it, Google requires you to verify ownership of the site. This was actually quite a simple mechanism: you place a TXT record with a value like google-site-verification=xxxx in the domain’s DNS.
When the ownership was verified, Google provided the specific link that was flagged. It was just the one, though they noted there might be more without giving any specifics. They also provided a review option, where you had to state not only how you fixed the original issue, but also how you will prevent similar issues in the future.
The most practical option here was to build a blocklist into AnchorURL, so it can refuse and disable links that point to malicious sites. Because the site is a hobby project with free access and no plan to monetize, I could use the Google Safe Browsing API for free to verify whether a URL is a known threat.
The integration works by downloading a compact list of hash prefixes of known malicious URLs. Most URLs will not match any prefix, which guarantees they are not on the threat list without making any API call. Only when a URL matches a prefix do you call the API to check the full hash. This design also has a nice privacy property: Google never learns which URLs you are checking, since a hash prefix matches thousands of unrelated URLs. The list is only a few megabytes, so it can be kept in memory in a set and looked up instantly.
One limitation worth noting is that Safe Browsing only knows about threats that have already been reported, so a brand-new phishing site could slip through when a link is created. This is why the links are also periodically re-checked and disabled if they have turned malicious in the meantime.
After integrating this, I provided the explanation to Google, and they reviewed and removed the site from the threats list in under a day.
Going forward
This minor incident actually turned into a great learning opportunity, where I had to build an interesting integration and plan out a real mitigation strategy. A URL redirector will always attract abuse, so this probably won’t be the last attempt, but now there is a system in place to catch it. With AnchorURL hopefully safe again, the next step for me is to look into performance. Most requests are still handled in under 2 ms, so it is quite fast, but there are also very few links. I’m already looking into some optimizations and expect to post more about that soon.