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

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

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

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

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

We also have an endpoint that allows instances to connect to each other to update the cache in the primary region. This uses internal URLs for that communication (via litefs-js), but as an 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 coming from the internal network. But I haven't found a way to do that yet. PRs welcome!

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

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 not need to actually connect to real services, this can be used as cp .env.example .env).

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

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

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

The Epic Stack has built-in support to prevent CSRF attacks. We use the remix-utils CSRF-related utilities to do this.

The Epic Stack has built-in support for honeypot fields. We use the remix-utils honeypot-related utilities to do this.

The Epic Stack uses a rate limiter to prevent abuse of the API. This is configured in the server/index.ts file and can be changed as needed. By default it uses express-rate-limit with the in-memory store. There are trade-offs with this simpler approach, but it should be relatively simple to externalize the store into Redis as that's a built-in feature to express-rate-limit.