Is chrome.google.com safe to use as a vendor?

chrome.google.com scored 78/100 on LynxRadar's security posture assessment. The domain partially meets security requirements with some gaps to address. 10 checks passed, 3 warnings, 2 critical issues across 16 passive checks including TLS, DMARC, security headers, breaches, and CVEs.

What TLS version does chrome.google.com use?

chrome.google.com uses TLSv1.3 with TLS_AES_256_GCM_SHA384. TLSv1.3 negotiated with TLS_AES_256_GCM_SHA384 (256-bit). Strong configuration with no deprecated protocols or weak ciphers detected.

Does chrome.google.com have DMARC configured?

Yes. chrome.google.com's DMARC policy is set to 'reject'. SPF record: yes. Strengths: DMARC policy set to reject (strongest); DMARC pct=100 — policy applies to all mail; Aggregate reports (rua) configured; SPF soft-fail (~all) configured; SPF DNS lookup count: 1/10 (within limit); DKIM keys published (custom selector names).

Does chrome.google.com have SPF configured?

Yes. SPF record: v=spf1 include:_spf.google.com ~all

Does chrome.google.com have security headers configured?

chrome.google.com has 2 of 5 recommended security headers. Present: CSP, X-Content-Type-Options. Missing: X-Frame-Options, Referrer-Policy, Permissions-Policy.

Has chrome.google.com been involved in a data breach?

No known breaches found. No known breaches found in public disclosure databases.

Does chrome.google.com have known CVE vulnerabilities?

Detected technologies: sffe. No version information exposed — CVE matching not possible (this is good practice).

Is chrome.google.com's SSL certificate valid?

Yes. Strengths: Certificate valid, 66 days remaining; Issued by Google Trust Services; 2156 certificates logged in CT; Certificates from 3 CAs: Google Inc, Google Trust Services, Google Trust Services LLC. Note: Wildcard certificate in use (*.domain) — covers all subdomains. Common practice; worth noting that compromise would affect all subdomains.

chrome.google.com Security Report — Grade C+ (78/100)

Q: Does chrome.google.com use HSTS?

No. Strict-Transport-Security header is missing. Connections can be downgraded to HTTP via man-in-the-middle attacks. If this domain is in the browser HSTS preload list, browsers may still enforce HTTPS — but the header should be present for full coverage.

Q: Does chrome.google.com have DNSSEC enabled?

No. Strengths: 4 nameservers configured (ns2.google.com, ns1.google.com, ns4.google.com, ns3.google.com); SOA record present and MNAME consistent with NS set; 1 MX record(s) present; Zone transfers properly restricted on all nameservers; Address records present: 1 A record(s), 1 AAAA record(s). Issues: All nameservers are from a single provider (google.com) — a provider outage takes down the domain; DNSSEC not configured — DNS responses can be spoofed or tampered with in transit (DNS cache poisoning).

C+

Trust rating

Fair · 78/100

Procurement snapshot

0 critical findings identified — these point to architectural gaps, not just configuration tweaks.

Strengths

MX Records & Mail Provider

TLS Protocol Support

TLS Configuration

MTA-STS & TLS Reporting

Questions to ask

Confirm DNSSEC rollout timeline

Estimated remediation effort: 1–3 days

Based on a passive external scan — supplement with vendor-provided attestations, not a replacement.

Trust Score Trend

→ No change 1 scan · Last scanned September 28, 2026

Score

100 75 50 25 0

C+

chrome.google.com

78/100

Compliance & Certifications

Not yet verified

SOC 2 Type II

Audit report not on file

3rd party · AICPA

ISO 27001

Certificate not on file

3rd party · accredited body

GDPR

DPA not on file

Self-reported

CCPA

Self-reported

Incident History

No public breaches on record

Security Posture

5 items need attention

10 passed

Turn on HSTS (forces browsers to always use HTTPS)

HSTS Header

< 1 hour High

This puts visitor logins and session data at risk of interception on untrusted networks. chrome.google.com doesn't send the HSTS header, so a browser can still be tricked into connecting over plain, unencrypted HTTP instead of HTTPS — an attacker on the same network (e.g. public wifi) can exploit that gap to intercept traffic. Turning HSTS on tells every browser "always use HTTPS for this site, no exceptions."

PCI-DSS 4.0Req 6.4.1

Required application security controls

NIST 800-53SC-8

Transmission confidentiality and integrity

How to fix this

1Add this response header to your site. If you manage your own server (nginx, Apache, IIS) or a CDN like Cloudflare, add it in that config. If your site is on a managed platform (Wix, Squarespace, Shopify, WordPress.com), search their help center for "custom headers" or ask their support — most support it, though a few don't.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

2Before adding it, make sure every subdomain (not just the main site) also works over HTTPS — HSTS applies site-wide.

3Confirm it's live: search "http header checker" and enter chrome.google.com.

4Once confirmed, submit the domain at hstspreload.org so browsers enforce HTTPS even on a user's very first visit.

HSTS guide

Report unlocked.

View all 10 passed checks

MX Records & Mail Provider

TLS Protocol Support

TLS Configuration

MTA-STS & TLS Reporting

DMARC / Email Security

Known Breaches

Cookie Security

Subprocessors & Tech Stack

CVE Exposure

Certificate Hygiene

Couldn't check: Malware / Phishing Blocklist — the check didn't complete (the site blocked or timed out our scanner, or a data source was unavailable), so this isn't counted in the score.

Company Signals

Operational risk

Last funding

Employees

Trust Resources

Claim profile →

Trust Center

Not detected

DPA (Data Processing Agreement)

Subprocessors List

Similar companies

Appears in

Vendors graded C

696 companies · LynxRadar ranking

Blocking Issues

Not enabled

Strict-Transport-Security header is missing. Connections can be downgraded to HTTP via man-in-the-middle attacks. If this domain is in the browser HSTS preload list, browsers may still enforce HTTPS — but the header should be present for full coverage.

Likelihood: ★★★☆☆

Impact: ★★★★☆

2/5 present

Missing: X-Frame-Options, Referrer-Policy, Permissions-Policy

Likelihood: ★★★☆☆

Impact: ★★★☆☆

Medium Priority

Not enabled

Strengths: 4 nameservers configured (ns2.google.com, ns1.google.com, ns4.google.com, ns3.google.com); SOA record present and MNAME consistent with NS set; 1 MX record(s) present; Zone transfers properly restricted on all nameservers; Address records present: 1 A record(s), 1 AAAA record(s). Issues: All nameservers are from a single provider (google.com) — a provider outage takes down the domain; DNSSEC not configured — DNS responses can be spoofed or tampered with in transit (DNS cache poisoning).

Likelihood: ★★☆☆☆

Impact: ★★★☆☆

Best Practice

Warn

Strengths: CAA records configured at google.com (1 record(s)); Authorised CAs: pki.goog. Issues: No iodef record — CA violations won't be reported to the domain owner.

Likelihood: ★☆☆☆☆

Impact: ★☆☆☆☆

Warn

No security.txt found. Publishing a security.txt at /.well-known/security.txt is the industry standard (RFC 9116) for vulnerability disclosure policies. Its absence may indicate a less mature security program.

Likelihood: ★☆☆☆☆

Impact: ★☆☆☆☆