Documentation

Check Status

DNS Records

InfraLens uses Node.js native DNS resolution to retrieve and analyze common DNS records. Results are cached in-memory to optimize performance. This provides visibility into hosting setup, email configuration, and domain delegation.

DNS Security (SPF/DMARC)

Checks the two email-authentication signals reliable enough to confirm pass/warning/fail on their own:

• SPF: Sender Policy Framework for email authentication — also flags multiple SPF records, which RFC 7208 treats as invalid
• DMARC: Domain-based Message Authentication — its policy (none/quarantine/reject) is reported, with p=none flagged as monitor-only, not real enforcement

Missing SPF/DMARC records, or a DMARC policy that only monitors instead of enforcing, may expose the domain to spoofing or delivery issues.

DKIM

DomainKeys Identified Mail signatures — checked only at a handful of commonly-used selector names, since the actual selector isn't published anywhere. Finding one is a real, confirmed pass; not finding one there is reported as inconclusive, never as "DKIM is missing" — a separate check from DNS Security above, since it can never reach a confirmed fail the way SPF/DMARC can.

DNSSEC

Always reported as inconclusive — Node's built-in DNS resolver doesn't support the DS/DNSKEY lookups DNSSEC validation requires, so this is reported as such rather than implied absent. A separate check, kept apart from DNS Security above for the same reason as DKIM.

IP & Hosting Information

InfraLens uses the ipapi.co API (optional) to identify public IP address, Autonomous System Number (ASN), hosting provider, geographic location, and IPv6 availability. This provides a high-level view of where and how the site is hosted. The API key is optional—the service works without it but with rate limits. Informational only — inventory, not a quality judgment, so it never affects the score.

Security Headers

InfraLens checks six recommended HTTP security headers — not just whether they're present, but whether their value is actually safe (e.g. a Content-Security-Policy that still allows unsafe-inline counts as weak, not strong). A check passes only when every header is present with a safe value; missing or weak headers trigger actionable recommendations.

HTTPS & TLS

This check verifies whether HTTPS is properly enforced and opens its own raw TLS connection to inspect the certificate — an invalid certificate fails the check, and one expiring within 30 days triggers a warning:

• HTTPS availability
• HTTP to HTTPS redirection
• Negotiated TLS protocol version
• Certificate issuer
• Certificate validity and expiration date

Redirect Behavior

InfraLens follows redirect chains (up to 10 redirects) to detect misconfigurations, including excessive redirects, redirect loops, and a chain that downgrades from HTTPS back to HTTP partway through (treated as a failure). Each hop's URL and status code is recorded, and a hostname change between the first hop and the final URL is surfaced as informational evidence. Clean redirect chains improve security, performance, and SEO.

security.txt

InfraLens checks for the presence of a security.txt file according to RFC 9116. This file provides security researchers with contact information and vulnerability disclosure policies. The check verifies:

• Presence at /.well-known/security.txt or /security.txt
• Required Contact field
• Required Expires field, and whether that date has already passed (an expired file is treated as a failure per RFC 9116)
• Other optional fields (Encryption, Acknowledgments, etc.)

A properly configured security.txt helps security researchers report vulnerabilities responsibly.

Firewall / WAF Detection

This check looks for known header fingerprints (Cloudflare, Fastly, Akamai, AWS CloudFront, Sucuri, and similar) that suggest a WAF or CDN may be in front of the site. This is always a probabilistic signal, never a confirmed detection — a real WAF can hide its fingerprint, and a header alone doesn't prove active filtering. It's informational only and never counts toward the score either way.

robots.txt

InfraLens checks for the presence of robots.txt, HTTP status, and basic syntax validity, and reports whether it disallows all crawlers under User-agent: * (an indexing signal, not a vulnerability) and which Sitemap: URLs it declares. robots.txt controls crawler access and indexing behavior.

Sitemap

This check tries the Sitemap: URL declared in robots.txt first, then falls back to /sitemap.xml and /sitemap_index.xml — at most 3 locations, never recursing into a sitemap index's child sitemaps. Signals include presence, format (XML / index), and basic URL count.

Linked Pages

InfraLens extracts links from the initial HTML document with lightweight regex-based parsing and categorizes them as internal or external. Up to 10 links are checked with HEAD requests to detect unreachable or broken links — this stays a signal, not a crawler.

HTML Metadata

Checks for title, meta description, charset, and viewport. Missing metadata affects accessibility and SEO.

Social Tags

InfraLens inspects Open Graph tags, Twitter Card metadata, and social preview images.

Stack Detection

InfraLens analyzes HTTP headers and HTML content to detect frontend frameworks, CMS platforms, analytics tools, and CDN providers — every finding is labeled with a confidence level rather than presented as certain: confirmed (an infrastructure-level header, not spoofable by page content), likely (a distinctive structural fingerprint, e.g. a build-output path), or possible (a single bare keyword match, the weakest signal). This check is purely informational and never affects the score.

Server Headers

This check looks for X-Powered-By exposure and other unusual headers, and flags the Server header only when its value discloses an actual version number (e.g. nginx/1.18.0) — a generic value like "nginx" or "cloudflare" alone isn't treated as an information leak.

Accessibility Hints

This is a lightweight static check, not a complete accessibility audit — it looks at a handful of observable HTML signals that affect screen readers and assistive technologies:

• lang attribute: Presence on the HTML element
• h1 heading: Presence and count (should be exactly one)
• Image alt text: Missing alt attributes on images
• ARIA landmarks: Semantic HTML elements and ARIA roles (header, nav, main, footer)
• Skip links: Presence of skip navigation links

These are basic checks and do not replace comprehensive accessibility audits, but they help identify common issues that impact users with disabilities.

Response Metrics

InfraLens collects performance signals from the server side — it doesn't replace Lighthouse, WebPageTest, or field Core Web Vitals, and never fabricates a metric it can't actually measure:

• Total response time (DNS + connect + TTFB + download combined — connection setup and TTFB aren't separately observable through a server-side fetch, so they're not reported individually)
• DNS lookup time for this analysis's own resolution
• Response size (Content-Length header or body size)
• Compression support (Content-Encoding: gzip, br, etc.) and the Cache-Control header

These are indicative signals from a single request, not comprehensive performance audits. Results may vary based on network conditions and server load.

Reachability Snapshot

InfraLens checks the response already collected to verify reachability, HTTP status code, and timeout handling. This represents a single point-in-time snapshot of the website's availability, not historical uptime tracking or monitoring.

Check Weights

Every check has its own point weight — not its category. Weights sum to exactly 100 across every genuinely scoreable check; informational-only checks (like WAF/CDN detection) have weight 0. A category's total is simply the sum of its checks' weights, shown here for a report where every check runs normally:

• HTTP & Security: 45 points
• Network & DNS: 14 points
• Infrastructure: 0 points (informational)
• Website Structure: 11 points
• Metadata & Stack: 17 points
• Performance: 13 points

Status Points

• Pass: 100% of the check's weight
• Warning: 60% of the check's weight
• Fail: 0% of the check's weight
• Info / Not applicable / Inconclusive / Unavailable / Error: excluded from the score entirely — never counted for or against the site

Final Grade

Grades (A–E) are visual aids only, not security certifications:

• 90–100: A (Strong configuration signals)
• 75–89: B (Good, with improvements available)
• 60–74: C (Mixed configuration)
• 40–59: D (Several important improvements)
• < 40: E (Major public configuration issues detected)