docs/security.md

The Epic Stack has several security measures in place to protect your users andyourself. This (incomplete) document, explains some of the security measuresthat are in place and how to use them.

The Epic Stack uses a strictContent Security Policy.This means that only resources from trusted sources are allowed to be loaded.However, by default, the CSP is set toreport-only which means that thebrowser will report violations of the CSP without actually blocking theresource.

This is to prevent new users of the Epic Stack from being blocked or surprisedby the CSP by default. However, it is recommended to enable the CSP inserver/index.ts by removing thereportOnly: true option.

The Epic Stack usesFly for hosting. Fly has an internalnetwork that allows you to connect services to each other without exposing themto the public internet. Only services within your organization have access tothis network, and only accounts in your organization have access as well.

When running multiple instances of the Epic Stack, your instances communicatewith each other over this internal network. Most of this happens behind thescenes with the consul service that Fly manages for us.

We also have an endpoint that allows instances to connect to each other toupdate the cache in the primary region. This uses internal URLs for thatcommunication (vialitefs-js), but asan added layer of security it uses a shared secret to validate the requests.

This could be changed if there's a way to determine if a request is comingfrom the internal network. But I haven't found a way to do that yet. PRswelcome!

Outside of this, the Epic Stack does not access other first-party services ordatabases.

The currently recommended policy for managing secrets is to place them in a.env file in the root of the application (which is.gitignored). There is a.env.example which can be used as a template for this file (and if you do notneed to actually connect to real services, this can be used ascp .env.example .env).

These secrets need to also be set on Fly using thefly secrets command.

There are significant limitations to this approach and will probably be improvedin the future.

React has built-in support for XSS protection. It does this by escaping allvalues by default. This means that if you want to render HTML, you need to usethedangerouslySetInnerHTML prop. This is a good thing, but it does mean thatyou need to be careful when rendering HTML. Never pass anything that isuser-generated to this prop.

The Epic Stack has built-in support to prevent CSRF attacks. We use theremix-utilsCSRF-related utilities to dothis.

The Epic Stack has built-in support for honeypot fields. We use theremix-utilshoneypot-related utilitiesto do this.

The Epic Stack uses a rate limiter to prevent abuse of the API. This isconfigured in theserver/index.ts file and can be changed as needed. Bydefault it usesexpress-rate-limit withthe in-memory store. There are trade-offs with this simpler approach, but itshould be relatively simple to externalize the store into Redis as that's abuilt-in feature to express-rate-limit.

There aren’t any published security advisories