Every URL you classify through our API is simultaneously checked against Google Web Risk
threat intelligence. One call returns the page's IAB content categories and a threat verdict in the
malware response field — covering phishing and social engineering,
malware distribution, and unwanted software — so your gateway, SIEM or onboarding pipeline gets
category and threat status in a single round trip.
Phishing is no longer a volume game played from a handful of long-lived domains. It is an industrialized, disposable-infrastructure business: attackers register a domain, deploy a kit cloned from a bank or SaaS login page, harvest credentials for a few hours, and abandon the domain before most blocklists have propagated. Anti-phishing research consistently finds that the operational window of a phishing page is measured in hours, not days — median lifetimes in published takedown studies sit under 24 hours, and a large share of campaigns do their damage in the first few hours after launch. A defense that updates on a daily or weekly cadence is structurally late to every campaign that matters.
By the time a domain appears on a static blocklist you licensed last quarter, the kit has rotated to a fresh domain. Median phishing-page lifetimes under a day mean detection has to be queried live, per URL, at the moment of the click — not synced from a stale feed.
Typosquats, homoglyphs, and "yourbrand-login-secure.com" combosquats impersonate your login pages to phish employees and customers alike. Each one is trivially cheap to register and visually indistinguishable in an email client or SMS message.
Attackers deliberately operate from domains too new to be in anyone's category database. "Unknown" is not a neutral verdict — newly-registered, never-before-seen domains are the single strongest phishing predictor, and treating them like established sites is how credentials walk out the door.
A secure web gateway or DNS resolver deciding whether to allow a connection has a latency budget of milliseconds — and many regulated deployments cannot ship every visited URL to a third-party cloud for scoring. Threat lookups have to work locally, at line rate.
Our categorization API does not treat security as a separate product bolted onto
content classification. Every URL submitted for classification is checked, inline, against
Google Web Risk — the same continuously updated threat intelligence that protects
Chrome and Google Search users — across three threat lists: SOCIAL_ENGINEERING (phishing
and deceptive pages), MALWARE (pages hosting or distributing malware), and
UNWANTED_SOFTWARE. The verdict comes back in the malware field of the same JSON
response that carries the IAB categories, so one integration gives your pipeline both the content answer and
the security answer. Around that core, the platform supplies the context signals a security team actually
uses to triage: domain age, web-filtering taxonomy categories, offline database deployment, and technology
fingerprinting.
Every categorization request is screened against Google's SOCIAL_ENGINEERING, MALWARE and
UNWANTED_SOFTWARE lists at query time. No second vendor, no second API call, no correlation job:
the malware field arrives in the same response as the categories, from the same
request your pipeline already makes.
A clean Web Risk verdict on a nine-day-old "Banking" lookalike is not the same as a clean verdict on a fifteen-year-old news site. Our domain age checker and the domain-age database supply registration age, so you can apply graduated policy to the newly-registered domains where phishing actually originates.
For enforcement points that cannot tolerate a network hop — secure web gateways, DNS resolvers, air-gapped environments — the 102-million-domain database deploys inside your infrastructure. Lookups are local, latency is memory-speed, and no visited URL ever leaves your network. See offline database deployment.
Threat verdicts handle the confirmed-malicious tail; the web-filtering taxonomy handles everything short of it — block "Hacking", "Piracy" and "Adult" outright, allow "Finance" only on aged domains, quarantine "Unknown". Category plus threat plus age is a complete policy language, not a binary allow/deny.
POST a URL to the web-content-filtering endpoint and the response carries the
classification alongside the malware field. A flagged URL returns the Web Risk threat class it
matched; a clean URL returns an explicit all-clear. There is nothing to correlate downstream — the
enrichment record for your proxy log, email pipeline or SIEM is complete in one round trip.
curl -X POST "https://www.websitecategorizationapi.com/api/iab/iab_web_content_filtering.php" \ -d "query=http://suspicious-login-portal.example" \ -d "api_key=YOUR_API_KEY" \ -d "data_type=url"
import requests
resp = requests.post(
"https://www.websitecategorizationapi.com/api/iab/iab_web_content_filtering.php",
data={
"query": url,
"api_key": API_KEY,
"data_type": "url",
},
timeout=60,
)
result = resp.json()
threat = result.get("malware", "no malware detected")
if threat != "no malware detected":
block(url, reason=threat) # e.g. SOCIAL_ENGINEERING
{
"classification": [
{"category": "Personal Finance", "value": 0.91},
{"category": "Business and Finance", "value": 0.06}
],
"malware": "SOCIAL_ENGINEERING",
"status": 200
}
{
"classification": [
{"category": "Technology & Computing", "value": 0.88},
{"category": "Business and Finance", "value": 0.09}
],
"malware": "no malware detected",
"status": 200
}
Note the combination: the page classifies as
finance content — exactly what a banking phish is engineered to look like — while the
malware field carries the Web Risk verdict that it is a social-engineering page. Either
signal alone is incomplete; together they are the whole story.
In a SOC pipeline the three signals compose into a graduated response instead of a binary one. A confirmed Web Risk hit blocks immediately; a young domain masquerading as a finance or login-adjacent category escalates for review even before any feed has flagged it; an aged, clean, expected category passes at full speed.
def enrich_and_triage(url, api_result, domain_age_days):
threat = api_result.get("malware", "no malware detected")
category = api_result["classification"][0]["category"]
if threat in ("SOCIAL_ENGINEERING", "MALWARE", "UNWANTED_SOFTWARE"):
return {"action": "BLOCK", "severity": "high",
"reason": f"Google Web Risk: {threat}"}
if domain_age_days < 30 and category in SENSITIVE_CATEGORIES:
# e.g. Personal Finance, Technology & Computing login portals
return {"action": "QUARANTINE", "severity": "medium",
"reason": f"{domain_age_days}-day-old domain classified as {category}"}
if domain_age_days < 30:
return {"action": "ALERT", "severity": "low",
"reason": "newly registered domain, category benign"}
return {"action": "ALLOW", "severity": "none",
"reason": f"aged domain, {category}, no Web Risk match"}
The malware field reports which of Google Web Risk's three threat lists
the URL matched. Each class describes a different attack — and warrants a different operational
response.
| Verdict | Threat class | What it means | Typical action |
|---|---|---|---|
| SOCIAL_ENGINEERING | Phishing & deceptive pages | The page impersonates a trusted entity — a bank login, a webmail portal, a parcel tracker — to trick visitors into surrendering credentials, payment details or personal data, or deceives them into a harmful action. | Block immediately; alert the user; if the lure imitates your own brand, initiate takedown. |
| MALWARE | Malware hosting & distribution | The URL hosts or distributes malicious software — trojanized installers, drive-by exploit pages, malware payload staging — that can compromise a visitor's device on download or visit. | Block at gateway and mail filter; sweep endpoints that already touched the URL; feed IOCs to your EDR. |
| UNWANTED_SOFTWARE | Deceptive / unwanted software | The page pushes software that violates transparent-behavior norms — bundlers that install undisclosed extras, browser hijackers, apps that resist uninstall or exfiltrate data without consent. | Block on managed fleets; warn-and-allow for consumer products, per policy. |
| no malware detected | Clean | The URL matched none of the three Web Risk threat lists at query time. | Apply normal category policy; weigh domain age for new domains. |
The authoritative confirmed-threat signal, queried live against Google's continuously updated lists. This is your zero-hesitation block trigger — when it fires, the page has been observed doing harm.
The strongest predictive signal. Phishing campaigns overwhelmingly run on domains registered days or weeks before the attack, precisely because reputation systems have nothing on file yet. Age converts "unknown" from a blind spot into a policy lever.
Context for graduated response. A page that classifies as Personal Finance on an unfamiliar domain deserves scrutiny a recipe blog does not — and category is what lets a filtering policy say so without blocking half the internet.
Infrastructure attribution for investigators. The technology detector exposes the stack behind a page, and phishing kits reuse infrastructure — the same analytics ID, CDN pattern or panel software links today's lure to last month's campaign.
Extract URLs from inbound mail and chat, classify them at delivery time, and hold anything with a Web Risk hit or a suspicious age-plus-category profile before the user ever sees the message.
Resolve the 102M-domain offline database locally for the bulk of traffic, and fall through to the real-time API only for domains the database has never seen — the long tail where fresh threats live.
Enrich proxy and DNS logs with category, threat verdict and domain age in one lookup, so triage playbooks rank alerts on evidence instead of drowning analysts in raw uncategorized-URL noise.
Screen candidate lookalike registrations continuously: a young domain, classified into your own industry's category, is the pre-weaponization fingerprint of an impersonation campaign — catch it before the first phish is sent.
The verdicts come from Google Web Risk, the threat corpus Google maintains continuously from its own crawling and abuse telemetry — the same intelligence that powers Safe Browsing warnings for billions of Chrome users. We query it live at classification time rather than syncing a snapshot, so the malware field reflects the list state at the moment of your request, not the state of a feed downloaded last night. For hour-lifetime phishing infrastructure, that difference is the whole game.
Web Risk is deliberately conservative — it is engineered to warn real users in a browser, where a wrong block on a legitimate site carries real cost, so a SOCIAL_ENGINEERING or MALWARE verdict is high-confidence and safe to act on automatically. The practical risk runs the other direction: pages too new to have been flagged yet. That is exactly why the platform pairs the verdict with domain age and content category — a graduated response (block confirmed threats, quarantine young sensitive-category domains, allow the aged and clean) covers the gap without over-blocking.
Both, in layers. The offline 102M-domain database answers the overwhelming majority of lookups locally — zero egress, zero added latency, ideal for gateway and resolver enforcement at line rate. The real-time API handles the tail: domains too new or too obscure for any database, which is statistically where phishing concentrates. Cache the API's answers into your local layer and each novel domain costs you exactly one round trip.
No. The malware field is part of the standard response from the web-content-filtering endpoint — same request format, same authentication, same latency envelope. If you are already categorizing URLs with us, you are already receiving the threat verdict; it is one if statement away from being enforced.
Send us your use case and traffic profile and we will scope the right mix of real-time screening and offline deployment — or start reading the API docs and wire up the malware field today.