Security

cookieOptions.sameSite: 'lax' blocks part of this, but not all of it. Browsers do not attach a SameSite=Lax cookie to a cross-site fetch or XMLHttpRequest, so an attacker's page cannot make authenticated API calls or read authenticated responses with the defaults in place.

SameSite does not stop a cross-site HTML form POST from creating a session. A top-level navigation may store a cookie with any SameSite value, even when that cookie would not have been sent on the request (RFC 6265bis, section 5.5). A form that posts query=mutation { login(...) } as application/x-www-form-urlencoded needs no CORS permission and no JavaScript, and the response sets a session cookie in the victim's browser. That is Login CSRF: the victim ends up browsing your store logged in as the attacker, and anything they enter after that (addresses, saved payment details, order history) sits in the attacker's account.

The control that stops this is Apollo Server's CSRF prevention, not SameSite and not CORS. Turn it on with apiOptions.csrfPrevention:

It rejects any POST whose content type is one a browser lets a form send (application/x-www-form-urlencoded, multipart/form-data, text/plain) unless the caller also sends Apollo-Require-Preflight or x-apollo-operation-name. Requests sent as application/json, which is what Vendure clients use for normal operations, are unaffected. GET requests carry no content type at all, so they are rejected too unless they send the header.

The default is false so that existing clients keep working. It is expected to change to true in a future major release.

The CORS default is a separate problem on top of that, and it becomes serious in these cases:

• cookieOptions.sameSite: 'none'. This is a common setting when the storefront is on a different site to the server. The browser now does attach the session cookie to cross-site requests, so any website can make fully authenticated calls as the logged-in user and read the responses. An origin allowlist is the only control that stops this.
• tokenMethod: 'bearer'. sameSite gives no protection here. The browser does not attach the token by itself, so an attacker page still needs to obtain a token first, for example through an XSS on your own origin. An origin allowlist removes the CORS step from that chain.
• One setting for both APIs. apiOptions.cors applies to the Shop API and the Admin API together. You cannot allow a storefront origin on /shop-api without allowing it on /admin-api as well, so keep the list to the origins that need both, and put the Admin API behind a gateway if you need tighter separation.

Set an explicit origin list in every case. It costs nothing and it is the one control that works for every session transport.

Use the HardenPlugin

It is recommended that you install and configure the HardenPlugin for all production deployments. This plugin locks down your schema (disabling introspection and field suggestions) and protects your Shop API against malicious queries that could otherwise overwhelm your server.

Install the plugin:

Then add it to your VendureConfig:

Harden the AssetServerPlugin

If you are using the AssetServerPlugin, it is possible by default to use the dynamic image transform feature to overload the server with requests for new image sizes & formats. To prevent this, you can configure the plugin to only allow transformations for the preset sizes, and limited quality levels and formats. Since v3.1 we ship the PresetOnlyStrategy for this purpose, and you can also create your own strategies.

OWASP Top Ten Security Assessment

The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.

It publishes a top 10 list of common web application vulnerabilities: https://owasp.org/Top10

This section assesses Vendure against this list, stating what is covered out of the box (built in to the framework or easily configurable) and what needs to be additionally considered.

1. Broken Access Control

Reference: https://owasp.org/Top10/A01_2021-Broken_Access_Control/

Out of the box:

• Vendure uses role-based access control
• We deny by default for non-public API requests
• Built-in CORS controls for session cookies
• Directory listing is not possible via default configuration (e.g. exposing web root dir contents)
• Stateful session identifiers should be invalidated on the server after logout. On logout we delete all session records from the DB & session cache.

To consider:

• Rate limit API and controller access to minimize the harm from automated attack tooling.

2. Cryptographic Failures

Reference: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

Out of the box:

• Vendure defaults to bcrypt with 12 salt rounds for storing passwords. This strategy is configurable if security requirements mandate alternative algorithms.
• No deprecated hash functions (SHA1, MD5) are used in security-related contexts (only for things like creating cache keys).
• Payment information is not stored in Vendure by default. Payment integrations rely on the payment provider to store all sensitive data.

To consider:

• The Vendure server will not use TLS be default. The usual configuration is to handle this at the gateway level on your production platform.
• If a network caching layer is used (e.g. Stellate), ensure it is configured to not cache user-related data (customer details, active order etc)

3. Injection

Reference: https://owasp.org/Top10/A03_2021-Injection/

Out of the box:

• GraphQL has built-in validation of incoming data
• All database operations are parameterized - no string concatenation using user-supplied data.
• List queries apply default limits to prevent mass disclosure of records.

To consider:

• If using custom fields, you should consider defining a validation function to prevent bad data from getting into the database.

4. Insecure Design

Reference: https://owasp.org/Top10/A04_2021-Insecure_Design/

Out of the box:

• Use of established libraries for the critical underlying components: NestJS, TypeORM, Angular.
• End-to-end tests of security-related flows such as authentication, verification, and RBAC permissions controls.
• Harden plugin provides pre-configured protections against common attack vectors targeting GraphQL APIs.

To consider:

• Tiered exposure such as an API gateway which prevents exposure of the Admin API to the public internet.
• Limit resource usage of Vendure server & worker instances via containerization.
• Rate limiting & other network-level protections (such as Cloudflare) should be considered.

5. Security Misconfiguration

Reference: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

Out of the box:

• Single point of configuration for the entire application, reducing the chance of misconfiguration.
• A default setup only requires a database, which means there are few components to configure and harden.
• Stack traces are not leaked in API errors

To consider:

• Ensure the default superadmin credentials are not used in production
• Replace the default apiOptions.cors setting of { origin: true, credentials: true } with an explicit list of the origins you serve
• Use environment variables to turn off development features such as the GraphQL playground
• Use the HardenPlugin in production to automatically turn of development features and restrict system information leaking via API.
• Use fine-grained permissions and roles for your administrator accounts to reduce the attack surface if an account is compromised.

6. Vulnerable and Outdated Components

Reference: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

Out of the box:

• All dependencies are updated to current versions with each minor release
• Modular design limits the number of dependencies for core packages.
• Automated code & dependency scanning is used in the Vendure repo

To consider:

• Run your own audits on your code base.
• Use version override mechanisms if needed to patch and critical Vendure dependencies that did not yet get updated.

7. Identification and Authentication Failures

Reference: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

Out of the box:

• Valid usernames are not leaked via mechanisms such as account reset
• Does not permit "knowlege-based" account recovery
• Uses strong password hashing (bcrypt with 12 salt rounds)
• Session identifiers are not exposed in API urls (instead we use headers/cookies)
• New session tokens always regenerated after successful login
• Sessions deleted during logout
• Cryptographically-strong, high-entropy session tokens are used (crypto.randomBytes API)

To consider:

• Implementing a multi-factor authentication flow
• Do not use default superadmin credentials in production
• Implementing a custom PasswordValidationStrategy to disallow weak/common passwords
• Subscribe to AttemptedLoginEvent to implement detection of brute-force attacks

8. Software and Data Integrity Failures

Reference: https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

To consider:

• Exercise caution when introducing new dependencies to your project.
• Do not use untrusted Vendure plugins. Where possible review the code prior to use.
• Exercise caution if using auto-updating mechanisms for dependencies.
• If storing serialized data in custom fields, implement validation to prevent untrusted data getting into the database.
• Evaluate your CI/CD pipeline against the OWASP recommendations for this point

9. Security Logging and Monitoring Failures

Reference: https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/

Out of the box:

• APIs for integrating logging & monitoring tools & services, e.g. configurable Logger interface & ErrorHandlerStrategy
• Official Sentry integration for application performance monitoring

To consider:

• Integrate with dedicated logging tools for improved log management
• Integrate with monitoring tools such as Sentry
• Use the EventBus to monitor events such as repeated failed login attempts and high-value orders

10. Server-Side Request Forgery (SSRF)

Reference: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_(SSRF)/

Out of the box:

• By default Vendure does not rely on requests to remote servers for core functionality

To consider:

• Review the OWASP recommendations against your network architecture