Practical Content Security Policy and Security Headers for Solo SaaS

Most indie SaaS and developer tools ship with the default security headers their framework or host provides. That is often enough for an early prototype. Once you accept real customer data, process payments, or embed third-party scripts, the defaults leave gaps that are easy to close with a short Content Security Policy and a handful of response headers. The work is mostly configuration, not new code, and it can be rolled out safely in stages.

This guide shows a minimal, practical path that solo founders can follow. It focuses on what each header does, how to introduce a Content Security Policy without breaking the app, and how to verify the result. Examples are illustrative; always test against your actual stack.

Why these headers matter for a small product

Browsers will execute almost any script, style, or resource that a page asks for unless you tell them otherwise. A Content Security Policy (CSP) is a set of rules that tells the browser which origins are allowed to supply scripts, styles, images, frames, and connections. Other headers reduce common attack surface: clickjacking, MIME-type confusion, and mixed-content issues.

For a solo founder the practical benefits are:

• Fewer ways an injected script or compromised third-party can run in your users’ browsers.
• Clearer signal to scanners and security questionnaires that basic controls exist.
• A written policy you can update when you add a new analytics or support widget.

You do not need a perfect score on every scanner on day one. A policy that matches what your product actually loads is more useful than a strict policy that breaks checkout or login.

Start with the non-CSP headers

These headers are low-risk and high-value. Add them first; most hosts and frameworks let you set them in a config file or middleware.

• Strict-Transport-Security (HSTS): tells browsers to use HTTPS for future visits. Start with a short max-age (for example a few hours) while you confirm everything works over HTTPS, then increase it. Include includeSubDomains only if every subdomain is also HTTPS.
• X-Content-Type-Options: nosniff: stops browsers from guessing MIME types. Almost never breaks anything.
• X-Frame-Options: DENY or SAMEORIGIN: prevents your pages from being framed by other sites (clickjacking). Use SAMEORIGIN if you intentionally embed your own app in an iframe; otherwise DENY is safer.
• Referrer-Policy: strict-origin-when-cross-origin: limits how much URL information is sent to third parties. Safe for most SaaS apps.
• Permissions-Policy: disables browser features you do not use (camera, microphone, geolocation, payment, etc.). Start by denying everything you do not need.

Illustrative example only: a founder adds the five headers above in their Next.js or Rails middleware. Login, billing, and the dashboard continue to work. No customer reports appear. The headers are now live for every response.

Introduce a Content Security Policy in report-only mode

A CSP can break pages if it blocks a script or style you actually need. The safe way to start is report-only mode: the browser reports violations but does not block anything.

1. Decide where the policy will live. Most frameworks support a middleware or a config that sets the Content-Security-Policy-Report-Only header.
2. Begin with a permissive policy that still gives you useful reports. A common starting point allows scripts and styles from your own origin and the specific third parties you already use (analytics, error tracking, payment processor, support chat).
3. Point the report-uri or report-to directive at an endpoint that can receive the violation reports. Many error trackers accept CSP reports; a simple logging endpoint also works.
4. Deploy and use the product yourself for a day or two. Check the reports. Each report shows the blocked resource and the page that requested it.
5. Adjust the policy until the only reports left are from browser extensions or clearly unwanted sources.

Do not copy a strict policy from a blog and paste it in. Start from the resources your pages actually load.

Move the policy from report-only to enforcing

Once the report-only header produces no unexpected violations for several days:

1. Change the header name from Content-Security-Policy-Report-Only to Content-Security-Policy.
2. Keep the same directives.
3. Deploy to a staging environment first if you have one, then to production.
4. Watch error logs and customer support channels for the next 24 hours. If something breaks (a payment form, an embedded video, a font), add the missing source to the policy and redeploy. You can temporarily switch back to report-only if needed.

A practical order of directives most solo SaaS products need:

• default-src 'self'
• script-src 'self' plus the exact domains for your analytics, error tracker, and payment provider
• style-src 'self' 'unsafe-inline' (many frameworks still need inline styles; tighten later if you can)
• img-src 'self' data: https: (or a tighter list)
• connect-src 'self' plus API domains and your error tracker
• frame-src or frame-ancestors as needed for any embeds
• base-uri 'self'
• form-action 'self'

Illustrative example only: after a week of report-only mode the founder sees violations only from a browser extension. They switch to the enforcing header. The Stripe checkout iframe continues to load because frame-src already included the payment domain.

Handle common third-party widgets

Each new script or iframe is a new source you must allow. Keep a short list in a note or comment next to the policy:

• Payment (Stripe, Paddle, Lemon Squeezy): usually requires specific script-src, frame-src, and connect-src entries. Their documentation lists the current domains.
• Error tracking (Sentry, etc.): needs script-src and connect-src.
• Analytics that you host yourself or that is cookieless: often only script-src or none at all if it is first-party.
• Support chat or help-desk widgets: frequently need several domains for scripts, frames, and websockets. Add them only if the widget is actually used.
• Fonts and CDNs: prefer self-hosting when practical so you do not need extra sources.

When you add a new widget, update the policy in report-only mode first, confirm it works, then enforce.

Verify the headers

After deployment check three things:

• Open the browser developer tools, reload a page, and look at the response headers. Confirm the security headers and the CSP are present.
• Visit a free header-check site or use a command-line tool to confirm the same headers are returned for your production domain.
• Trigger a known violation (for example by temporarily adding a script from a disallowed domain in a local test) and confirm it is blocked or reported as expected.

Also test the critical paths: signup, login, billing form, file upload, and any embedded content. A policy that looks correct in the header but blocks the payment script is worse than no policy.

Practical checklist before you call the headers done

• HSTS, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), Referrer-Policy, and Permissions-Policy are set on all responses.
• A Content Security Policy exists and was first tested in report-only mode.
• The policy lists only the origins your product actually uses for scripts, styles, images, and connections.
• Payment, error-tracking, and any support widgets still function after the enforcing policy is live.
• Violation reports (if any) are going to a place you check occasionally.
• You have a short note that lists every third-party domain in the policy and why it is there.
• Critical user flows (auth, billing, file upload) were manually tested after the change.
• The headers are applied to both HTML pages and API responses where relevant.

Common pitfalls

• Adding a strict CSP that blocks 'unsafe-inline' or 'unsafe-eval' while the framework still emits inline scripts or styles, breaking the page.
• Forgetting to include the payment provider’s domains, so the checkout form never appears.
• Setting HSTS with a long max-age and includeSubDomains before every subdomain supports HTTPS.
• Leaving the policy in report-only mode forever and never enforcing it.
• Adding a new marketing script months later and never updating the CSP, so the script is silently blocked.
• Copying a CSP from another project that uses different third parties.

When the simple headers are no longer enough

Revisit the setup when:

• You add multiple new third-party scripts or embeds and the policy becomes hard to keep accurate.
• A security questionnaire or customer requires a documented CSP with specific directives.
• You start serving user-generated HTML or running untrusted code in the browser and need a tighter policy plus additional sandboxing.
• Automated scanners repeatedly flag missing headers that your current host does not let you set easily.

Until then, the non-CSP headers plus a CSP that was introduced in report-only mode and then enforced will close the most common browser-side gaps for an early SaaS or developer tool. The policy should stay short enough that you can update it in a few minutes when the product changes.

Security headers are configuration that pays off every time a page loads. A policy that matches what you actually ship is more valuable than a perfect score you cannot maintain.