feedbackqueue.dev

Architecture Risk & System Assessment

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

1. Executive Summary

Domain: feedbackqueue.dev
Detected Stack:

  • hosting: Resolves to IP 151.101.2.15
  • edge: Fastly
  • server: railway-edge
  • ssl: Let's Encrypt
  • email: DKIM: selector(s) present: default
  • routing: http→https redirect
  • app: railway-edge
  • frontend: Next.js (React)
  • payments: Stripe
  • analytics: Sentry, PostHog

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 ["feedbackqueue.dev"]
        server["railway-edge"]
        frontend["Next.js (React)"]
    end

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

    Browser -->|HTTPS| server
    server --> frontend
    frontend --> Sentry
    frontend --> PostHog
    frontend --> Google_Analytics
    frontend --> Stripe

3. Architecture Fitness

This setup is functional for early users and development workflows. Fastly in front of your origin (apex 151.101.2.15) 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.

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 a key dependency goes down:

  • Stripe outage → payment processing blocked

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
Domain Registrar $1–2 ~$12-20/yr amortised monthly
Fastly $0 Free tier (100 GB + 1M requests/mo)
Let's Encrypt $0 Free (automated renewal via ACME)
PostHog $0 Free (1M events/mo)
Railway $5 Hobby ($5/mo credit included)
Redis (managed) $0 Upstash free tier or self-hosted on EC2
Sentry $0 Developer (free, 5K errors/mo)
Stripe $0 2.9% + $0.30 per transaction
Estimated total $6–7/mo
  • Domain Registrar: Typical .com registration; premium TLDs cost more
  • Redis (managed): May be on the same host — cost not additive
  • Sentry: ~25 estimated errors/mo at this tier
  • Stripe: ~$16/mo at 50 tx/mo — excluded from total (volume-dependent)

Next cost drivers: Fastly, PostHog, Redis (managed), 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 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.