h1bpulse.com

Architecture Risk & System Assessment

External observation of publicly visible signals. Not a security audit — no active testing, no source access.

1. Executive Summary

Domain: h1bpulse.com
Detected Stack:

  • hosting: Resolves to IP 185.158.133.1
  • edge: Cloudflare (cf-ray)
  • server: cloudflare
  • ssl: Google Trust Services
  • email: DMARC policy none
  • routing: http→https redirect
  • app: cloudflare
  • frontend: JavaScript SPA (framework not detected)
  • dns: Google Domains
  • database: Supabase

System Maturity: Early-stage — functional but not yet hardened for sustained traffic

Top Findings:

  1. 🟡 Medium — API errors return HTML instead of JSON
    Error pages are showing internal framework details like stack traces and file paths.
  2. 🟡 Medium — Rate limiting not detected on public endpoints
    Your API endpoints don't appear to have rate limiting.
  3. 🟡 Medium — Domain trust risk (missing DMARC)
    Anyone can send emails pretending to be from your domain.

If this architecture remains unchanged:

  • Expect integration and monitoring issues due to SPA catch-all routing swallowing well-known paths
  • Expect degradation or downtime under traffic spikes — no rate limiting is in place
  • Expect email deliverability issues and domain trust degradation without email authentication records
  • Expect silent production failures — errors accumulate undetected until users report them

2. Architecture Snapshot

Textual stack signals are in §1 Executive Summary only. Here: diagram (if any) and HAR-backed runtime detail.

flowchart LR
    subgraph user [User]
        Browser
    end

    subgraph infra ["h1bpulse.com"]
        server["cloudflare"]
        frontend["JavaScript SPA (framework not detected)"]
    end

    subgraph sub_www ["www.h1bpulse.com"]
        sub_www_svc["cloudflare"]
    end

    subgraph external [External Services]
        Google_Analytics["Google Analytics"]
    end

    Browser -->|HTTPS| server
    server --> frontend
    Browser --> sub_www_svc
    frontend --> Google_Analytics

Detected backends (from HAR):

Captured from authenticated browser session. Reflects actual runtime traffic.

Host Service API Calls Transferred Sample Paths
wxvzllkvjtewlwiohgxi.supabase.co Supabase 14 552.7 KiB /rest/v1/app_config, /rest/v1/signals
www.google-analytics.com — 3 60 B /g/collect
h1bpulse.com — 1 80 B /~api/analytics

3. Architecture Fitness

This setup is functional for early users and development workflows. Cloudflare in front of your origin (apex 185.158.133.1) covers the basics, but several operational and architecture gaps will become problems as traffic and team size grow.

🟡 Medium — API errors return HTML instead of JSON observed

What this means: Error pages are showing internal framework details like stack traces and file paths.
When it hurts: This gives detailed knowledge of your tech stack, file structure, and potentially sensitive configuration.
What to do next: Enable production mode in your framework to suppress debug output on error responses.

Evidence: Inconsistent error format: API errors return HTML (consider application/json for /api/*).

🟡 Medium — SPA fallback masks well-known and API discovery paths inferred

What this means: Your SPA catch-all returns 200 OK for every URL path, including well-known discovery endpoints.
When it hurts: Monitoring tools, search engines, and security scanners can't distinguish real pages from missing ones. It also hides API routing bugs.
What to do next: Configure your web server to return proper 404 responses for /.well-known/, /robots.txt, and /api/ paths.

Evidence: SPA fallback is overly broad and swallows well-known and API discovery paths (robots.txt, security.txt, openid, swagger, graphql → 200 HTML). Real production smell.

⚪ Info — SPA catch-all may mask server-side fetch or proxy endpoints inferred

What this means: The SPA catch-all makes it impossible to tell from outside whether server-side proxy endpoints exist.
When it hurts: If the backend has URL-fetching routes, they could be used to reach internal services — but we can't confirm this externally.
What to do next: Audit any server-side fetch or proxy routes and restrict target URLs to an explicit allowlist.

Evidence: SPA fallback routes well-known paths to HTML; server-side URL-fetching endpoints, if present, are not externally discoverable.

4. Dependency Risk Profile

No dependency-level risks identified from external observation.

5. Operational Readiness

Email Deliverability

🟡 Medium — Domain trust risk (missing DMARC) observed

What this means: Anyone can send emails pretending to be from your domain.
When it hurts: When someone sends phishing emails as you — your domain reputation tanks and your real emails land in spam.
What to do next: Add a DMARC DNS record. Start with p=none to monitor, then tighten to p=quarantine or p=reject.

Evidence: DMARC record not configured or set to p=none with no reporting.

🟡 Medium — Domain trust risk (missing SPF record) observed

What this means: There's no SPF record telling email servers which IPs can send as your domain.
When it hurts: Phishing becomes trivial, and legitimate emails from your domain get flagged or rejected.
What to do next: Add an SPF TXT record listing your authorized senders (Google Workspace, your transactional email service, etc.).

Evidence: No SPF TXT record detected in DNS.

Observability

🟡 Medium — No error monitoring detected observed

What this means: No error tracking service (like Sentry) was detected in your frontend.
When it hurts: Errors hit production and nobody knows until users complain. Security incidents also go unlogged.
What to do next: Add Sentry, Bugsnag, or equivalent. Most have free tiers that cover early-stage traffic.

Evidence: No Sentry, Datadog, New Relic, or similar error-tracking SDK found in client bundle or HAR traffic.

Edge Protection

🟡 Medium — Rate limiting not detected on public endpoints observed

What this means: Your API endpoints don't appear to have rate limiting.
When it hurts: When bots or abusive users hammer your endpoints, causing slowdowns or outages for real users.
What to do next: Add rate limiting at your reverse proxy or API gateway. Most platforms offer this as a built-in feature.

Evidence: No X-RateLimit-, RateLimit-, or Retry-After headers observed in responses.

Routing & Headers

🔵 Low — Standard hardening headers absent observed

What this means: Some standard security headers are missing from your HTTP responses.
When it hurts: These are low-effort best practices. Missing them mostly matters for compliance checklists and defense-in-depth.
What to do next: Add the missing headers in your web server or CDN configuration — usually a few lines of config.

Evidence: Headers not observed: X-Frame-Options, Permissions-Policy.

⚪ Info — No responsible disclosure policy published observed

What this means: There's no security.txt file telling researchers how to report vulnerabilities.
When it hurts: If someone finds a bug, they have no clear way to reach you — which may lead to public disclosure instead of a private report.
What to do next: Publish /.well-known/security.txt with a contact email and policy link (RFC 9116).

Evidence: /.well-known/security.txt not found or returns SPA HTML (catch-all fallback).

⚪ Info — Certificate authority not restricted (no CAA record) observed

What this means: Any certificate authority can issue TLS certificates for your domain.
When it hurts: If a rogue CA issues a cert for your domain, someone could impersonate your site. Rare but preventable.
What to do next: Add a CAA DNS record restricting issuance to your CA (e.g., letsencrypt.org).

Evidence: No CAA (Certificate Authority Authorization) record detected in DNS.

6. Failure Scenarios

Scenarios below are derived from detected signals only. If a signal is absent, the scenario is omitted.

If traffic suddenly increases:

  • API endpoints may degrade or become unresponsive — no throttling is in place

If bots or abusive traffic targets your endpoints:

  • No throttling in place — sustained scraping or abuse has no automated circuit-breaker

If the application starts failing silently:

  • No error tracking means failures accumulate silently before anyone notices

7. Cost Profile

⚠️ Incomplete coverage: Detected stack entries — hosting (Resolves to IP 185.158.133.1, cloudflare) — are not matched by any recognised cost plugin for those categories. The table below reflects only identified SaaS services. Actual costs for unmatched categories are unknown and may be significant.

Tier: indie (~500 users). External observation only — actual costs depend on usage patterns and contracts.

Service $/mo Plan
Cloudflare $0 Free (CDN, DDoS, DNS)
Domain Registrar $1–2 ~$12-20/yr amortised monthly
Let's Encrypt $0 Free (automated renewal via ACME)
Mixpanel $0 Free (20M events/mo)
PostHog $0 Free (1M events/mo)
Sentry $0 Developer (free, 5K errors/mo)
Supabase $0 Free (up to 50K MAU auth, 500MB DB)
Identified services subtotal $1–2/mo (infrastructure costs not included)
  • Domain Registrar: Typical .com registration; premium TLDs cost more
  • Sentry: ~25 estimated errors/mo at this tier

8. Recommended Next Steps

Prioritized by impact — architecture and operational issues first, hygiene last.

  1. Fix routing for well-known and API paths
    (prevents hidden bugs, unblocks proper 404 handling, and improves monitoring reliability)
  2. Standardize API error responses to return JSON
    (prevents framework details from leaking and makes frontend error handling predictable)
  3. Fix domain email authentication (add DMARC and SPF records)
    (stops anyone from sending email as your domain and protects deliverability)
  4. Add error monitoring (Sentry or equivalent)
    (gives visibility into production failures before users report them)
  5. Enable rate limiting at the edge or API gateway
    (protects against traffic spikes, bot floods, and application-layer abuse)
  6. Add standard hardening response headers
    (low-effort hygiene that satisfies compliance checklists and adds defense-in-depth)
  7. Add a CAA DNS record
    (restricts which certificate authorities can issue TLS certificates for your domain)

9. Scope & Limitations

This assessment is based on external observation of publicly visible signals:

  • DNS records (A, AAAA, MX, TXT, CAA, NS)
  • HTTP/HTTPS response headers and status codes
  • TLS certificate metadata
  • HTML source and JS bundle fingerprinting
  • Subdomain discovery (HTML, headers, DNS, JS, HAR, and Certificate Transparency from public providers — wildcard + identity queries)

This assessment does NOT include:

  • Active exploitation or penetration testing
  • Source code review
  • Authentication bypass or session testing
  • Internal network, database, or infrastructure access
  • Dynamic application testing (DAST)
  • Compliance review (PCI, HIPAA, SOC 2)

Findings reflect the external footprint visible to an unauthenticated observer and architectural inferences drawn from public signals. A comprehensive review requires authenticated testing, source access, and infrastructure visibility.