Skip to main content
Version: Canary

Security

CedarJS wants you to be able build and deploy secure applications and takes the topic of security seriously.

⚠️ Security is Your Responsibility While Cedar offers the tools, practices, and information to keep your application secure, it remains your responsibility to put these in place. Proper password, token, and key protection using disciplined communication, password management systems, and environment management services like Doppler are strongly encouraged.

Security Policy and Contact Information The CedarJS Security Policy is located in the codebase repository on GitHub.

To report a potential security vulnerability, contact us at security@cedarjs.com.

Authentication​

@cedarjs/auth is a lightweight wrapper around popular SPA authentication libraries. We currently support the following authentication providers as well as a self-hosted solution (dbAuth):

  • Netlify Identity Widget
  • Auth0
  • Azure Active Directory
  • Netlify GoTrue-JS
  • Magic Links - Magic.js
  • Firebase's GoogleAuthProvider
  • Ethereum
  • Supabase
  • Nhost

For example implementations, please see Authentication and the use of the getCurrentUser and requireAuth helpers.

For a demonstration, check out the Auth Playground.

GraphQL​

GraphQL is a fundamental part of Cedar. For details on how Cedar uses GraphQL and handles important security considerations, please see the GraphQL Security section and the Secure Services section.

Malicious Document Requests​

The CedarJS GraphQL handler sets reasonable defaults to prevent abusive queries that attackers often use to exploit systems.

Disable Introspection and Playground​

Because both introspection and the playground share possibly sensitive information about your data model, your data, your queries and mutations, best practices for deploying a GraphQL Server call to disable these in production, by default CedarJS only enables introspection and the playground when running in development.

note

For more information on how to enable introspection in production, please see the GraphQL Docs.

Functions​

When deployed, a serverless function is an open API endpoint. That means anyone can access it and perform any tasks it's asked to do. In many cases, this is completely appropriate and desired behavior. But there are often times you need to restrict access to a function, and Cedar can help you do that using a variety of methods and approaches.

For details on how to keep your functions secure, please see the Serverless functions & Security considerations section in the CedarJS documentation.

Webhooks​

Webhooks are a common way that third-party services notify your CedarJS application when an event of interest happens.

They are a form of messaging or automation and allows web applications to communicate with each other and send real-time data from one application to another whenever a given event occurs.

Since each of these webhooks will call a function endpoint in your CedarJS api, you need to ensure that these run only when they should. That means you need to:

  • Verify it comes from the place you expect
  • Trust the party
  • Know the payload sent in the hook hasn't been tampered with
  • Ensure that the hook isn't reprocessed or replayed

For details on how to keep your incoming webhooks secure and how to sign your outgoing webhooks, please see Webhooks.

Signed Tokens​

Some values have to leave your api side and come back through an untrusted channel: the state parameter of an OAuth flow, a confirmation or unsubscribe link in an email, a short-lived token that grants one specific action. Rather than storing a nonce somewhere and checking it later, you can mint a token that carries its own claims and expiry and is signed with a secret only your app knows.

@cedarjs/api exports createSignedToken and verifySignedToken for exactly this. Each token is bound to a named purpose so it cannot be replayed in a different flow, always expires, and verification throws rather than returning null, so a forgotten check cannot fail open. Tokens are signed, not encrypted: anyone who holds one can read its payload, so keep secrets, sensitive personal data, and internal references you would not expose in a URL out of it and carry only the ids the receiving code needs.

A signed token proves where a value came from, not which browser is presenting it, and verification is stateless, so a valid token is accepted until it expires. Two independent additions cover what that leaves out: a cookie-bound nonce ties a flow to the browser that started it, which OAuth login and account linking need, and recording each nonce as it is consumed makes a token single-use, which password-set and confirmation links need even though they may be opened from any browser. The OAuth example shows both.

For details, please see Signed Tokens.