Guide

All communication between your app, the Signalshoot API, and the dashboard is encrypted with TLS 1.3.

HTTPS is enforced on every endpoint — there is no way to send or receive data over an unencrypted connection.

Each app gets two API keys: a live key (fb_live_) for production and a test key (fb_test_) for development.

Test submissions are stored separately and do not appear in your production inbox.

API keys are hashed using SHA-256 before storage — we never store them in plain text.

If a key is compromised, you can regenerate it from Settings.

The old key is immediately invalidated.

Dashboard access requires OAuth authentication via GitHub.

Sessions use cryptographically secure tokens (20 bytes of randomness, SHA-256 hashed) stored in an HttpOnly, Secure, SameSite=Lax cookie.

Sessions expire after 30 days and are automatically extended when more than half the duration has passed.

There are no passwords to leak or brute-force — authentication is delegated entirely to the OAuth provider.

Every database query is scoped to the authenticated developer's app ID.

Developer A cannot access Developer B's feedback, even by guessing feedback IDs.

The getFeedback query requires both a feedback ID and the app ID to match.

There is no admin backdoor or shared data space.

Every HTTP response from the Signalshoot dashboard includes the following security headers: X-Frame-Options: DENY (prevents clickjacking), X-Content-Type-Options: nosniff (prevents MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), microphone=(), geolocation=() (blocks unnecessary browser permissions), X-XSS-Protection: 1; mode=block.

The API also returns X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and X-XSS-Protection headers on all responses.

Signalshoot runs entirely on Cloudflare's global edge network.

This provides built-in DDoS protection, automatic TLS certificate management, and low-latency responses worldwide.

Data is stored in Cloudflare D1 (SQLite-based) with platform-managed backups.

There are no self-managed servers to patch or maintain.

All user input is validated server-side before storage. type: required, max 50 characters. message: required, max 5,000 characters. channel: max 100 characters. tags: max 50 tags, each max 100 characters. notes: max 10,000 characters. replies: max 5,000 characters.

Invalid or oversized input is rejected with a descriptive error.

SQL injection is prevented by parameterized queries (D1 prepared statements).

XSS is mitigated by React's automatic output escaping.

For mobile apps (iOS, Android, React Native, Flutter), the API key is embedded in the app binary.

This is an accepted industry practice — the key identifies your app, not a user.

The API key cannot access the dashboard or modify existing feedback.

It can submit new feedback and retrieve feedback messages and replies for a specific user_id via the replies endpoint.

If your app uses predictable user IDs (e.g. sequential integers), consider using opaque identifiers (e.g.

UUIDs) to prevent enumeration.

To mitigate abuse if a key is leaked: regenerate the key from Settings, and the old key is immediately rejected.

For web apps, we recommend keeping the API key on your server (not in client-side JavaScript) to prevent exposure in browser source code.

You are responsible for: ensuring you have appropriate consent to collect feedback data from your end users (especially if it may contain personal information), keeping your API keys secure and regenerating them if compromised, the content of feedback submitted through your app (Signalshoot stores it as-is without content filtering), and managing the type, channel, and metadata values your app sends (the API accepts any valid string without semantic validation).