Skip to main content

Security

note

This section is currently not exhaustive.

This document describes the different security measures and deployment settings provided by Saleor.

Looking to report a security issue instead? See our Security Policy.

External Connectivity​

HTTP Redirects and Timeouts​

Out of the box, Saleor disables HTTP redirects for outgoing connections, and sets a strict timeout value (typically <20s).

This is a design choice intended to prevent potential Denial of Service (DoS) attacks from being done by internal actors.

Without such measure in place, a malicious staff user could, for example, create an infinite redirection loop in a malicious endpoint and exhaust server resources.

Timeout settings cannot be overridden dynamically. However, they can be altered inside settings.py.

IP Address Filtering (SSRF Protection)​

This section describes the IP address filtering capabilities of Saleor Core. By default, Saleor rejects any outgoing traffic to private and loopback IP addresses.

This behavior prevents malicious staff users from accessing inward-facing resources, which could lead to unauthorized access to resources you may deploy within your networks or even gaining a foothold (such as achieving lateral movements to gain more privileges).

For in-depth details, refer to:

Implementation Details:

  • IP Addresses are Pinned: the resolved IP address for each outgoing HTTP(S) request is pinned, meaning that a malicious actor cannot set-up round-robin DNS responses or use race-condition attacks (Time-of-Check) to trick Saleor into connecting to a different IP address after validation.
  • IP Address Validation for Each Request: validation is ran before sending each and every HTTP(S) request. This prevents a malicious actor from changing the DNS records after adding a non-malicious URL inside the database.

Settings:

Caveats:

  • Allow-Lists: it is not currently possible to put given IP addresses into an allow-list (or block-list). It currently only supports: "block-all" or "allow-all".

Additional Capabilities:

  • Proxies: SOCKS and HTTP proxies can be used in combination with the IP Filtering.

    • The IP address used to establish the proxy tunnel itself is not restricted. However, any HTTP requests sent through the proxy will be filtered based on their destination IP address.

      For example, setting HTTPS_PROXY=socks5://10.0.0.1:8888 is allowed, but attempting to access https://10.0.0.2 through the tunnel will be blocked.

    • Can be configured through environment variables, such as:

      $ export HTTP_PROXY="http://10.10.1.10:3128"
      $ export HTTPS_PROXY="http://10.10.1.10:1080"
      # Alternatively:
      $ export ALL_PROXY="http://10.10.1.10:1080"

  • HTTP redirects: each redirection is checked whether it points to a private or loopback IP address range.

Restricted File Uploads​

Out of the box Saleor restricts the type of files that can be uploaded in mutations like fileUpload() and digitalContentCreate() (list may not be exhaustive).

This is done in order to limit the risks of misuse from staff users who could upload malicious files like .html, .svg, or even .exe. By default Saleor only allows popular file formats but if needed you can relax it using the UPLOAD_ADDITIONAL_ALLOWED_MIME_TYPES environment variable.

note

You shouldn't allow dangerous file formats (e.g., HTML or SVG), instead prefer using zip files to reduce the risks of the browser rendering them.

Saleor's behavior is as follows:

  • Saleor checks the file extensions to determine whether the file extension is allowed.
  • AND Saleor checks whether the file's MIME matches the file extension, e.g., if image.png but has the MIME text/html then it's rejected.

We highly recommend that you also return Content-Disposion: attachment in HTTP responses for the media files to further reduce risks, for example, if you use AWS Cloudfront you can follow our AWS Best Practices.

EditorJS & HTML Cleaning​

Saleor accepts HTML in rich text fields (such as product descriptions, pages, collections, etc.), under the hood it cleans the untrusted HTML inputs using nh3 and Ammonia. These libraries rely on strict allow-lists for HTML elements, attributes, and attribute values to mitigate the risks of XSS attacks.

Our cleaner can be configured through the following settings:

  • EDITOR_JS_ALLOWED_ATTRIBUTES (docs) - a list of HTML attributes to allow for given HTML elements. For example, if you want to allow users to pass my-attr for all <a> elements, then you this is the correct environment variable to modify.
  • EDITOR_JS_ALLOWED_ATTRIBUTE_VALUES (docs) - a list of values allowed inside given attributes within a given element, this a stricter version of the previous setting: instead of allowing all values, it only allows the given values.
  • EDITOR_JS_LINK_REL (docs) - controls which values to put in the rel attribute for links (<a href=... rel="XXX">). We recommend setting both noopener and noreferrer, at minimum noopener.
  • UNSAFE_EDITOR_JS_ALLOWED_URL_SCHEMES (docs) - a list of allowed URL schemes. By default we allow only HTTP(S) links, telephone numbers and mailto addresses.
  • EDITOR_JS_LISTS_MAX_DEPTH (docs) - limits the list depth for nested list from EditorJS - defaults to 10, meaning you can have indentation 10 levels in lists (typically a person only uses max 3 levels).

PCI DSS​

Diagrams representing payment-related data flow: