Best practices using Web Risk API to help stop phishing and more

Whether you are a social media site, security company, or enterprise email manager, keeping users safe is always the goal. However, the top two threats to users’ security, phishing and malware, can make that challenging. The Safe Browsing teamat Google has been dedicated to defending the web from malware, phishing, and more threats for more than a decade. Google scans more than a billion links on a daily basis to produce a list of over one million malicious URLs related to phishing, social engineering, malware, and unwanted software.

Over the last couple years, we’ve introduced an enterprise-ready tool that builds on the technology used in Safe Browsing and adds new features to make the Web Risk API. Web Risk API enables any enterprise to have access to Google’s phishing and malware data to confirm if a URL is malicious. Today, we are going to share with you our best practices for how to use all of Web Risk APIs together to protect your business from web-based attacks. 

How Web Risk API Works

Users can submit a URL to the Web Risk API to see if it is safe or unsafe. The URLs that Web Risk can assess can be submitted from any platform or device in your company that connects to the internet. A few common sources for potentially malicious URLs are: 

User Generated Content: For large social media sites, it’s common for attackers to directly post or social engineer other users to share viral malicious links. 

Emails: Internally or externally sourced emails are the primary entry vector for spreading phishing and malware

User Reports: Enterprises will often have a [email protected] reporting address or form to enable users to report phishing either sent from your infrastructure or attempting to present using your brand identity (logos, messaging, login details)

Enterprise user activity observed via a firewall or CASB

Referral Links: Attackers often link directly to a real customer site to source content/images. Looking at traffic to these resources can often expose this type of early fraud.

Once you have the results back from the Web Risk API, your security team or automated system will be able to quickly take action to block the content and run remedial analysis to understand any action a compromised user may have taken. If a user is compromised by phishing, their account should be reset and the user notified that any data in the account has been exposed. If a user is compromised by malware, the user’s device and software will often need to be reset to ensure the malware has been fully removed. Additionally, any user accounts accessed since the time of the malware compromise should be considered at risk. 

How Web Risk API’s 4 APIs Work

Due to the variety of fraudulent URLs, Web Risk provides you with a few different URLs to help you detect spam and abuse.

Lookup API: Submit a URL and see if the URL is good or bad.

Update API: Store a list of partial hashes of malicious URLs. We recommend you do a local comparison and send any matches to the Web Risk API which will return a full hash. This method requires more implementation than the Lookup API, but primarily uses calls to a local database and does not require transmission of a full URL.

Evaluate API : Submit a URL and receive a risk type and confidence score assessment. While the Update and Lookup APIs are a result of confirmed malicious behavior, the Evaluate API relies on the URL’s reputation. This has the advantages of not requiring a crawl of the URL and also it is not as vulnerable to URL spoofing or cloaking. 

Submissions API: Enables companies to submit URLs directly to the Safe Browsing blocklist. Any URLs found to be on the violating policy list will be added to the Safe Browsing blocklist, which is consumed by more than 4 Billion devices worldwide (including many non-Google platforms). This broad scope enables us to help defend customers from virtual phishing, brand impersonation phishing, and other types of user attacks that are being distributed outside the control of a company’s own infrastructure.

How to Use All the Web Risk APIs Together To Protect Your End Users

We recommend that these URLs be used together and as follows: 

An initial call to the Update API can be made to determine if a URL is known to be malicious .  This is the best first call due to the speed of response (local hash comparison). 

If the Update API doesn’t return a malicious verdict, the next call can be made to the Evaluate API (server call) to determine if the URL contains any other signals of risk.

Finally, if you would like Google to crawl the URL or know the URL to be bad, you can submit to the Submissions API. This API will do a full crawl of the URL and add it to the Safe Browsing Blocklist if found to be malicious.

These calls can be made in this prescribed order or parallel. Also, if you have an internal risk model or analyst team you can combine these signals as input to your own detection models.

Once a malicious URL has been found, the action that you need to take depends on the channel the URL exists in.

Emails: Block access via web proxy, log to SIEM, follow up on exposed users/devices

User Reports: Submit URL to Safe Browsing, block malicious link on all company control platforms

User Generated Content: Remove link from user-facing content.  Investigate the user who posted.  Note – many users propagate malicious content unknowingly. 

Enterprise user activity observed via a firewall or CASB: Block access via web proxy, log to SIEM, follow up on exposed users/devices

Referral Links: Attackers often link directly to a real customer site to source content/images.  Submit URL to Safe Browsing, block malicious link on all company control platforms

Defending against phishing and malware to prevent account compromise is a never ending battle. The Web Risk API team is dedicated to providing tools to keep your users safe. To get started with Web Risk API, contact our sales team.