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

• RedwoodJS Security on GitHub
• CodeQL code scanning
• Authentication
• Webhook signature verification
• Ways to keep your serverless functions secure
• Environment variables for secure keys and tokens

⚠️ Security is Your Responsibility While Redwood 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 RedwoodJS Security Policy is located in the codebase repository on GitHub.

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

@redwoodjs/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 is a fundamental part of Redwood. For details on how Redwood uses GraphQL and handles important security considerations, please see the GraphQL Security section and the Secure Services section.

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

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 RedwoodJS 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. :::

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 Redwood 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 RedwoodJS documentation.

Webhooks are a common way that third-party services notify your RedwoodJS 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 RedwoodJS 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.