Is pages.wifi.care safe to use as a vendor?

pages.wifi.care scored 78/100 on LynxRadar's security posture assessment. The domain partially meets security requirements with some gaps to address. 9 checks passed, 4 warnings, 2 critical issues across 16 passive checks including TLS, DMARC, security headers, breaches, and CVEs.

What TLS version does pages.wifi.care use?

pages.wifi.care 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 pages.wifi.care have DMARC configured?

Yes. pages.wifi.care'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 hard-fail (-all) configured; SPF DNS lookup count: 1/10 (within limit). Note: DKIM couldn't be confirmed from outside (custom selector names can't be looked up, and some DNS hosts don't expose them), so it isn't counted against the score.

Does pages.wifi.care have SPF configured?

Yes. SPF record found: v=spf1 include:spf.protection.outlook.com ip4:103.103.156.0/24 ip4:103.103.157.1...

Does pages.wifi.care have security headers configured?

pages.wifi.care has 0 of 5 recommended security headers. Missing: CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.

Has pages.wifi.care been involved in a data breach?

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

Does pages.wifi.care have known CVE vulnerabilities?

Detected technologies: LiteSpeed, CyberPanel-OLS/2.5.1. No high or critical CVEs found for detected versions.

Is pages.wifi.care's SSL certificate valid?

Yes. Strengths: Certificate valid, 67 days remaining; Issued by Let's Encrypt; 66 certificates logged in CT.

pages.wifi.care Security Report — Grade C+ (78/100)

Q: Does pages.wifi.care 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 pages.wifi.care have DNSSEC enabled?

No. Strengths: 5 nameservers configured (ns1.no-ip.com, ns5.no-ip.com, ns3.no-ip.com, ns2.no-ip.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). Issues: All nameservers are from a single provider (no-ip.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

DMARC / Email Security

TLS Configuration

Known Breaches

Questions to ask

Confirm MTA-STS rollout plans for inbound email

Estimated remediation effort: 1–4 days

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

Trust Score Trend

→ No change 7 scans · Last scanned October 13, 2026

Score

100 75 50 25 0

C+

pages.wifi.care

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

6 items need attention

9 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. pages.wifi.care 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 pages.wifi.care.

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 9 passed checks

MX Records & Mail Provider

DMARC / Email Security

TLS Configuration

Known Breaches

Cookie Security

Subprocessors & Tech Stack

TLS Protocol Support

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

702 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: ★★★★☆

0/5 present

Missing: CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy

Likelihood: ★★★☆☆

Impact: ★★★☆☆

Medium Priority

Warn

Issues: No MTA-STS configured — email in transit is vulnerable to TLS downgrade attacks; sending servers cannot verify your mail server requires TLS; No TLSRPT record (_smtp._tls) — TLS delivery failures won't be reported to the domain owner.

Likelihood: ★★☆☆☆

Impact: ★★★☆☆

Not enabled

Strengths: 5 nameservers configured (ns1.no-ip.com, ns5.no-ip.com, ns3.no-ip.com, ns2.no-ip.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). Issues: All nameservers are from a single provider (no-ip.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

No CAA records found in the DNS tree for this domain. Without CAA, any Certificate Authority can issue certificates for this domain. Adding CAA records restricts issuance to authorised CAs only, reducing the risk of misissued certificates.

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: ★☆☆☆☆