Fireandstorm.com Public Test Assessment

Full report

On this page

Executive summary

The public assessment of fireandstorm.com could not be completed to the depth requested because the browser-oriented research harness was unable to fetch the site’s public root and returned 502 Bad Gateway for the main host. That single failure blocked the rest of the live-site workflow: reliable crawling, page rendering, screenshot capture, interactive form checks, Lighthouse runs, header inspection, cookie inspection, authentication-path validation, and role-based workflow verification from the public entry point. In practical terms, the highest-confidence finding is not a confirmed OWASP flaw on the application itself, but a public reachability and observability failure that prevents a credible security, UX, accessibility, and SEO attestation of the live site.

A second important boundary is that the role-specific login, pending-user, approval, and admin-review behaviors were available only in the uploaded QA specification, not through a successful live crawl. That specification clearly defines expected public-safe routes, portal routes, pending-account behavior, and admin approval endpoints, so it is useful as a test model. It is not, however, evidence that those routes were discoverable or functioning on the live public website during this assessment.

Because of that constraint, the report below separates high-confidence live findings from expected but unverified behaviors. It also preserves the requested deliverables by providing machine-readable artifacts for the site map, route matrix, role-gating matrix, command log, and security findings, while being explicit about what remained untestable on the live host. The benchmark standards used for remediation recommendations are WCAG 2.1, Chrome Lighthouse, Google Core Web Vitals guidance, RFC 6797 for HSTS, RFC 6265 for cookies, and W3C CSP guidance.

Scope and evidence base

The requested scope matched a broad QA and security program: crawl the site, test public and portal routes, verify login and registration flows, assess pending-user and role-approval behavior, review internal-admin endpoints, inspect access control, and audit UI/UX across desktop and mobile viewports. The uploaded QA prompt was especially useful for identifying the intended route inventory and the expected approval model, including public-safe routes such as /site-unavailable, /support-fallback, /fallback-drill-status, and /ai-help-status, plus portal routes for contractor, adjuster, and property-owner roles.

For live evidence, the most reliable site-specific datum was the failed browser fetch of the root host. Since that failure occurred at the front door, the remainder of the live public path could not be credibly evaluated. For standards and remediation, the report relies on primary or near-primary documentation: W3C’s WCAG 2.1 Recommendation, Chrome for Developers’ Lighthouse documentation, Google Search Console’s Core Web Vitals guidance, RFC 6797 for HSTS, RFC 6265 for cookies, MDN’s HSTS reference, and the W3C CSP specification.

The compact site map below therefore distinguishes between what was actually observed on the live site and what was only seeded from the uploaded QA scope.

Live-site findings

The highest-confidence live finding is a public availability and testability blocker. A site whose root URL cannot be fetched consistently in a browser-oriented harness cannot be meaningfully attested for public security headers, route behavior, page content, rendered accessibility, performance, or SEO readiness. That is especially important because Lighthouse expects a reachable URL and is explicitly designed to run audits against public or authenticated web pages, including performance, accessibility, and SEO categories.

That live blocker cascades into several areas that remained unverified rather than passing. No trustworthy statement can be made, from this pass, about whether the live site currently uses HTTPS correctly, redirects HTTP to HTTPS, emits HSTS, publishes an effective CSP, sets Secure and HttpOnly flags on sensitive cookies, avoids exposing internal admin content to unauthenticated users, or prevents role confusion between contractor, adjuster, and property-owner accounts. Those were all part of the requested verification scope, but the site’s failed public entry point interrupted the entire chain of evidence.

The result is best summarized as a coverage matrix rather than as a pass/fail certification:

Role and workflow expectations

The uploaded QA scope describes a fairly specific role-gating model: users can register independently for contractor, adjuster, and property-owner roles; pending users may reach the correct portal shell; pending users must not receive work payloads; and approval must be exact-role only. It also defines admin review cards, approval preflight, the review mutation path, and post-decision queue follow-through. That model is internally coherent and provides a strong expected-state target for the next assessment pass.

The diagram below shows the expected approval flow derived from the uploaded scope. It should be read as a test hypothesis, not as proof that the live public website currently implements it correctly.

flowchart LR
    A[Public user registers for a role] --> B[Account created as pending]
    B --> C[User signs in to role-specific portal shell]
    C --> D[Portal shell visible]
    D --> E[Work payloads remain blocked]
    F[Internal admin opens review queue] --> G[Read-only approval preflight]
    G --> H{Approve or reject}
    H -->|Approve| I[Exact selected role becomes approved]
    H -->|Reject| J[Exact selected role remains blocked or rejected]
    I --> K[Only that role's work features unlock]
    J --> L[Other roles remain unaffected]

From an access-control perspective, this model places the heaviest security weight on broken access control and approval scoping: the site should never let approval of one role alter the state of another role for the same person, and pending users should never receive work payloads merely because they can reach a shell. Those are the tests that deserve highest priority after reachability is repaired.

Remediation priorities

The most urgent remediation is to restore consistent public reachability for the root host. Until fireandstorm.com loads successfully in a browser path, every downstream result will be speculative. The practical debugging order should be redirect chain, DNS resolution, CDN or WAF behavior, TLS negotiation, origin availability, host-header handling, and any user-agent-specific filtering that may be returning an edge-generated 502. This is the prerequisite for all later QA, not a parallel workstream.

Once the root is stable, the next priority should be a transport and header baseline. HSTS is defined by RFC 6797 and must be delivered over secure transport, not plain HTTP; the max-age directive controls the HSTS lifetime, and browsers should not accept the HSTS header over insecure transport. MDN likewise notes that Strict-Transport-Security tells browsers to use HTTPS for future requests and not allow click-through on certificate errors for that host. This makes an immediate follow-up check for HTTPS redirect behavior, HSTS presence, and certificate hygiene essential.

After transport, harden the session layer. RFC 6265 defines Cookie and Set-Cookie, and specifies that the Secure attribute limits cookie transmission to secure channels while HttpOnly prevents script access to cookies through non-HTTP APIs. For authenticated sessions and admin review paths, those attributes should be treated as mandatory defaults rather than optional hardening.

Then deploy or validate a real CSP. W3C’s CSP specification describes CSP as a defense-in-depth mechanism against content injection and XSS, delivered through the Content-Security-Policy response header; it also explicitly supports Content-Security-Policy-Report-Only so teams can observe breakage before enforcement. Chrome Lighthouse includes checks for effective CSP, HTTPS use, HSTS, clickjacking protections, and vulnerable front-end JavaScript libraries, so that combination should become the core browser-based hardening pass once the site is reachable.

Accessibility and responsive UX should then be retested as complete rendered processes, not isolated pages. WCAG 2.1 is a W3C Recommendation, it applies to web content across device types, and it defines conformance levels A, AA, and AAA. The AA-level criteria added in WCAG 2.1—such as orientation, reflow, non-text contrast, text spacing, content on hover or focus, and status messages—map directly to the kinds of registration, validation, and pending-approval experiences described in the uploaded QA scope.

Finally, rerun performance and SEO audits with Lighthouse and compare them against Google’s field-metric guidance. Google’s Core Web Vitals documentation describes LCP, INP, and CLS and provides thresholds for “good,” “needs improvement,” and “poor.” The Lighthouse documentation also shows that Lighthouse audits performance, accessibility, SEO, and best practices, and includes checks for invalid HTTP status codes, invalid robots.txt, missing meta descriptions, missing canonical elements, unreadable fonts, and poorly sized tap targets. That is the right basis for the next full audit as soon as the host is loadable.

Artifacts and reproducibility

The requested artifacts have been prepared in a way that preserves what was actually established, while clearly flagging blocked or unverified items. The files are available here:

Site map CSV Route matrix CSV Role-gating matrix CSV Command and log text Security findings markdown Screenshots ZIP

The command log includes both the live browser fetch attempts that failed at the root and the reproducible follow-on commands that should be run in a local shell or CI runner once the host is reachable again. That follow-on toolchain centers on Lighthouse, curl redirect and header checks, TLS validation, and vulnerability scanning. Chrome’s Lighthouse docs explicitly support DevTools, CLI, and Node-based execution against any URL, including authenticated paths, which makes it the correct first browser-grade automation after the reachability issue is fixed.

Representative reproducible commands from the artifact set are shown below for convenience:

curl -I http://fireandstorm.com/
curl -I https://fireandstorm.com/
curl -Lsv http://fireandstorm.com/ -o /dev/null

npx lighthouse https://fireandstorm.com \
  --preset=desktop \
  --output=json \
  --output-path=./lighthouse-desktop.json

npx lighthouse https://fireandstorm.com \
  --screenEmulation.mobile=true \
  --output=json \
  --output-path=./lighthouse-mobile.json

npx pa11y https://fireandstorm.com/
testssl.sh fireandstorm.com
nuclei -u https://fireandstorm.com -severity low,medium,high,critical

Open questions and limitations

This report is intentionally conservative. It does not claim that fireandstorm.com currently lacks HSTS, CSP, secure cookies, proper RBAC, or accessible forms. It claims only that the live public site could not be fetched reliably enough to verify those items from the public entry point in this pass.

Likewise, the route inventory and workflow model are best understood as an expected-state test blueprint extracted from the uploaded QA prompt, not as proof that those routes and flows were present and working live on the public host during assessment. The most important unresolved questions are therefore simple: whether the root host can be restored to a stable browser-openable state, whether the live public routes match the uploaded scope, and whether the exact-role approval logic behaves as specified once authenticated testing becomes possible.