This page documents controls that can be verified in the public fireintel.net implementation and separates them from assurances that must be confirmed for an authenticated deployment.
At a glance
- Verified public-site controls
- Explicit domain-check boundaries
- Deployment-specific assurance
Controls verified in the public website
The public website consolidates indexable pages on the HTTPS apex domain and applies response headers that restrict framing, MIME sniffing, referrer detail, and access to camera, microphone, and geolocation features.
The walkthrough endpoint accepts same-origin JSON only, limits request size, rejects unknown fields, validates expected values, uses a honeypot, and applies source and email rate limits. These statements describe this website implementation; they are not a certification statement for every FireIntel service.
- HTTPS apex-domain canonicalization for public pages.
- Strict walkthrough-request validation and abuse controls.
- Security headers applied by the Cloudflare Worker.
How a walkthrough request moves
A walkthrough request contains the contact and workflow information visible in the form. The Worker creates a request identifier, rate-limits pseudonymous hashes derived from the source address and email, and delivers the validated request as email to support@fireintel.net through Cloudflare Email Routing.
XRILAND has no KV, D1, R2, or application-database binding for these requests. The email mailbox and Cloudflare infrastructure still process the message, so the absence of an XRILAND database should not be interpreted as an absence of retention elsewhere.
The public domain-check boundary
The domain check sends the submitted domain to the public FireIntel XTI summary endpoint and can return security-related aggregates. Result pages withhold usernames and passwords, send no-store and noindex directives, and require an authorization confirmation before the browser requests the summary.
That confirmation is not technical proof of domain ownership. Only check a domain you own, control, or are explicitly authorized to assess. A noindex directive controls search-engine handling; it is not an access-control mechanism.
Assurance for authenticated deployments
Authenticated FireIntel workspaces can have different data sources, roles, retention, exports, integrations, and deployment boundaries. Those controls must be confirmed for the exact scope being evaluated rather than inferred from the public website.
A professional evaluation should review the evidence trail, who may access sensitive records, tenant and organizational scope, events retained for review, supported exports, and the handoffs into existing security operations.
Responsible security contact
Potential vulnerabilities can be reported to support@fireintel.net. Begin with a concise, non-sensitive description and avoid destructive testing, persistence, social engineering, denial of service, or accessing data that does not belong to you.
The security page explains the initial reporting boundary. It is not a public bug-bounty or reward commitment.