Google Safe Browsing

Google Safe Browsing is the warning system embedded in Chrome, Firefox, Safari, and Edge. When a domain is flagged, every visitor sees a full-screen red interstitial ("Deceptive site ahead", "Dangerous site", "The site ahead contains malware") before reaching your content. Mail providers also use the feed as a deliverability signal, search rankings drop, and embedded apps using browser components inherit the same warnings. RedScore queries Google's Safe Browsing API and gives full credit when clean, zero when flagged.

How the check works

Per scan, RedScore queries the Google Safe Browsing v4 API for the domain. The API returns either a clean response or a list of threat matches (malware, phishing, unwanted software, etc.). The score is binary:

• Clean: 1.0 (full 15 pts).
• Flagged: 0.0 (fail). Reason: google_safe_browsing_flagged.
• API key not configured / API error: deferred (no score).

How the verdict maps to evidence

• Pass: domain is not in any GSB threat list.
• Fail: domain matches at least one GSB threat. Evidence shows the threat type from the API response.
• Deferred: GSB API key not configured for the scanner instance, or an API call failed transiently. The check returns no score with an evidence note.

Special states

• Deferred (no_key): GSB API key not configured. The scanner cannot evaluate this check; the result is reported but does not contribute to your score.
• Deferred (error): the API call returned an error. Re-run the lookup; if it persists, the API may be experiencing an outage.

Fail: investigate via Search Console, then remediate, then request review

If your domain is flagged, treat it as the highest-priority security finding in this scan. Real users are seeing browser warnings on every page load. Three steps:

1. Identify the specific threat

Go to Google Search Console (search.google.com/search-console). Add and verify your domain if you have not already. The Security Issues panel shows what GSB found:

• Malware: files served from your domain match malware signatures (often hosted JS, document files, or exploit kits).
• Social engineering / Phishing: pages on your domain match phishing patterns (fake login pages, brand impersonation).
• Unwanted software: software hosted on your domain triggers PUA (potentially unwanted application) detection.
• Deceptive content: pages mislead users into actions they would not take (fake download buttons, fake security warnings).

Search Console gives you specific URLs that triggered the flag. Start with those.

2. Remediate the underlying issue

• Malware: remove the malicious files from your server. Audit recent uploads, check for webshells, scan your full document root with malware tools, look for unauthorized cron jobs and scheduled tasks. Rebuild from a clean backup if compromise is widespread.
• Phishing: take down the phishing pages immediately. If they were uploaded by a customer or user-generated, audit the upload pipeline and add scanning. Reset compromised credentials.
• Unwanted software: remove the software downloads. Audit your CDN and download paths.
• Deceptive content: remove the deceptive UI elements. Sometimes triggered by aggressive ad networks or redirect chains; audit those.

Do not request a review until you have actually fixed the issue. Google's reviewers will re-flag if they see the threat is still present, and repeat re-flag triggers a longer cooling-off period before the next review.

3. Request review

In Search Console → Security Issues, click "Request Review". Provide a clear, factual description of what you removed and what changes you made to prevent recurrence. Google typically reviews within 24 to 72 hours; the warning lifts shortly after a passing review.

While waiting: warn users via your status page or out-of-band channel. The browser warning will stay up until Google clears it.

Verify the fix

• Check the live status at https://transparencyreport.google.com/safe-browsing/search?url=yourdomain.tld. The page shows the current Safe Browsing status for your domain.
• Test in Chrome: visit your domain in incognito mode. If the warning is gone, the listing has cleared.
• Search Console will email the verified owner when the issue is resolved.
• Re-run the RedScore lookup. The score recovers once GSB no longer reports a match.

Common pitfalls

• Requesting review before fixing. Re-flag triggers a longer cooling-off. Fix, then verify, then request.
• Removing malware but leaving the entry vector. Webshells often re-deploy malware after removal. Identify and close the entry path (vulnerable plugin, leaked credentials, exposed admin panel).
• Customer-uploaded content getting your domain flagged. If users can upload files served under your domain, you carry the flag. Implement upload scanning (ClamAV, VirusTotal API, cloud-provider malware scanners) and content moderation.
• Subdomain or path flagged but you scanned the apex. GSB flags can be at the URL, path, or domain level. Use Search Console to see exactly which URLs triggered.
• Believing the deferred state means clean. "No key" means the scanner did not actually check. Configure the GSB API key in the scanner config to enable the check; deferred is honest, not pass.
• Repeat offenders flagged faster. Google maintains a history of past flags; sites with prior flags get re-flagged on lighter signals. Establish good security hygiene to avoid the repeat-offender pattern.
• GSB flags propagate to other browsers slowly. Chrome usually clears immediately after Search Console review; Firefox can take additional hours; Safari uses a related but distinct list (Tencent Safe Browsing in some regions). Check multiple browsers before declaring fully clear.