How Chromium Uses the Safe Browsing API to Block Phishing
This article explains the technical process of how the Chromium web browser integrates the Google Safe Browsing API to detect and block phishing websites. It covers the privacy-preserving hash prefix system, local database checks, server-side verification protocols, and how the browser ultimately triggers a warning screen to protect the user from deceptive content.
The Local Database and Privacy
Chromium does not send every visited URL to the Safe Browsing servers by default. Instead, it uses the Safe Browsing Update API to download a local database of known phishing and malware threats directly to the user's device. To save bandwidth and protect user privacy, this local database does not contain actual URLs. It only stores 32-bit "hash prefixes"—the first four bytes of a cryptographic SHA-256 hash—of known malicious URLs. Chromium automatically updates this compressed local list in the background every 30 minutes.
URL Formatting and Hashing
When a user types a web address or clicks a link, Chromium intercepts the network request before the page begins to render. The browser processes the URL through the following steps:
- Canonicalization: Chromium standardizes the URL by removing unnecessary elements, resolving relative paths, and converting characters into a standard format.
- Expression Generation: The browser breaks the URL down into multiple host-suffix and path-prefix combinations to ensure both the specific page and the broader domain are checked.
- Hashing: Chromium applies a SHA-256 hashing algorithm to each of these URL variations, turning the plain text web addresses into obscured 256-bit strings of data.
The Local Prefix Match
Chromium takes the first 32 bits of the newly generated URL hashes and compares them against its local Safe Browsing database.
- No Match: If the 32-bit prefix is not found in the local database, the website is deemed safe. The browser allows the network request to proceed, and the page loads normally. The vast majority of web browsing ends at this step, ensuring zero network latency and complete privacy.
- Match Found: If the 32-bit prefix matches an entry in the local database, the URL is flagged as suspicious. However, because 32 bits is very short, multiple safe and unsafe URLs can share the same prefix (a hash collision). Chromium must now verify the full 256-bit hash.
Full Hash Verification
When a local prefix match occurs, Chromium initiates a network request to the Safe Browsing API servers. It sends the matching 32-bit prefix and asks the server to return all known malicious 256-bit full hashes that begin with that exact prefix.
This step preserves user privacy. Because Chromium only sends the partial 32-bit prefix rather than the full hash or the plain text URL, the Safe Browsing server cannot deduce the exact website the user is attempting to visit.
Blocking the Phishing Site
Once Chromium receives the list of full 256-bit hashes from the Safe Browsing API, it compares them locally against the full 256-bit hash of the URL the user is trying to visit.
- False Positive: If the full hashes do not match, the browser recognizes it as a benign hash collision, caches the result to prevent repeat checks, and loads the webpage.
- Confirmed Phishing: If the full hash of the visited URL matches one of the full hashes returned by the server, the site is confirmed as a phishing threat. Chromium immediately cancels the network request, blocks the DOM from rendering, and injects a local HTML warning page (the red interstitial screen) into the tab. This warns the user that the site ahead is deceptive and prevents them from entering sensitive data.
Real-Time Protection
Because modern phishing sites frequently appear and disappear in a matter of minutes, the 30-minute update cycle for the local database can sometimes lag behind brand-new threats. To counter this, Chromium also includes an optional "Enhanced Protection" mode.
When a user enables this feature, Chromium bypasses the local prefix database whenever the user visits an unfamiliar URL (a site not present in a local list of known, safe global domains). The browser strips irrelevant data from the URL and sends it directly to the Safe Browsing Lookup API in real time. The server evaluates the URL against live threat intelligence and instantly returns a safe or unsafe verdict to the browser before the page loads.