httpsornot.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: httpsornot.com
Detected Stack:

  • hosting: Resolves to IP 172.67.209.95
  • edge: Cloudflare (cf-ray)
  • server: cloudflare
  • ssl: Google Trust Services
  • email: DMARC policy none
  • routing: http→https redirect
  • app: cloudflare
  • analytics: Sentry
  • dns: Cloudflare
  • origin: Railway

Deployment style (inferred): PaaS (managed)

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

Top Findings:

  1. 🟡 Medium — Rate limiting not detected on public endpoints
    Your API endpoints don't appear to have rate limiting.
  2. 🟡 Medium — Domain trust risk (missing DMARC)
    Anyone can send emails pretending to be from your domain.
  3. 🟡 Medium — Domain trust risk (missing SPF record)
    There's no SPF record telling email servers which IPs can send as your domain.

If this architecture remains unchanged:

  • 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

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 ["httpsornot.com"]
        server["cloudflare"]
    end

    subgraph sub_api ["api.httpsornot.com (Railway)"]
        sub_api_svc["Railway"]
    end

    subgraph sub_contact ["contact.httpsornot.com (Railway)"]
        sub_contact_svc["Railway"]
    end

    subgraph sub_report ["report.httpsornot.com (Railway)"]
        sub_report_svc["Railway"]
    end

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

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

    Browser -->|HTTPS| server
    Browser --> sub_api_svc
    Browser --> sub_contact_svc
    Browser --> sub_report_svc
    Browser --> sub_www_svc
    server --> Sentry
    server --> Google_Analytics

3. Architecture Fitness

This setup is functional for early users and development workflows. A Cloudflare-fronted Railway deployment covers the basics, but several operational and architecture gaps will become problems as traffic and team size grow.

No architecture-level findings from external observation.

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.

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

⚪ 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.

⚪ Info — Authentication mechanism not externally identifiable observed

What this means: No standard authentication protocol (OIDC/OAuth) was detected.
When it hurts: If auth is custom-built, it's statistically more likely to have vulnerabilities than a standard protocol.
What to do next: If your app has authentication, consider adopting an OIDC/OAuth2 provider or documenting your auth scheme.

Evidence: No /.well-known/openid-configuration or OAuth redirect flow observed.

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

7. Cost Profile

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
Google Fonts $0 Free (Google-hosted CDN)
Let's Encrypt $0 Free (automated renewal via ACME)
Railway $5 Hobby ($5/mo credit included)
Sentry $0 Developer (free, 5K errors/mo)
Estimated total $6–7/mo
  • Domain Registrar: Typical .com registration; premium TLDs cost more
  • Sentry: ~25 estimated errors/mo at this tier

Next cost drivers: Cloudflare, Sentry are currently on free tiers. As usage grows, these will be the first services to cross into paid plans.

8. Recommended Next Steps

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

  1. Fix domain email authentication (add DMARC and SPF records)
    (stops anyone from sending email as your domain and protects deliverability)
  2. Enable rate limiting at the edge or API gateway
    (protects against traffic spikes, bot floods, and application-layer abuse)
  3. 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 via crt.sh — wildcard + identity queries; subject to crt.sh availability)

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.