Security Positioning Statement

Elastic Path is committed to delivering products that support our customers’ security policies and allow deployment in hardened computing environments.

Application Security

The following sections detail how Elastic Path Commerce ensures application-level security.

Software Design and Development Practices

The Elastic Path Commerce product team follows an Agile software development lifecycle that includes the following elements:

• Business requirement definition by a Product Manager.
• Technical design definition by Solution Architects.
• Implementation and code review by Software Engineers.
• Testing by Quality Assurance Engineers.

Elastic Path addresses security at all of these stages of the development lifecycle.

Product Managers ensure that business requirement stories contain functional security constraints, such as "As a shopper, I should not be able to view purchases placed by other shoppers." These functional security constraints are validated for accuracy and completeness through a review process with the Solution Architecture team.

Solution Architects regularly consult Open Web Application Security Project (OWASP) recommendations for design of security features. The team adheres to OWASP recommendations for SQL injection prevention, password storage, authentication, logging, and so on. Researching and following industry standard security recommendations is a standard part of the technical design phase of Elastic Path’s development lifecycle.

Software Engineers follow coding and code review best practice guides, which include security guidelines. Elastic Path’s source code control tools prevent pull requests from being merged unless:

• All unit, integration, and system tests pass.
• All automated source code verification checks pass.
• At least one code review has been completed with approval by an authorized engineer.

Quality Assurance Engineers test edge cases around security boundaries. For example, the team attempts to manually generate API URLs rather than simply following links to attempt gain access to other users resources.

Elastic Path uses multiple automated source code verification tools to detect functional and security issues. These include Checkstyle, PMD Source Code Analyzer, and SonarQube. Elastic Path’s pipeline does not allow code to be merged to master unless it passes these checks.

Elastic Path Commerce depends on many open source libraries for core functionality. We use Whitesource to scan our releases for known vulnerabilities in all dependencies. Elastic Path regularly upgrades dependent libraries and the underlying technologies, such as Java, Tomcat and database technologies.

Input Validation

Input is validated at multiple layers of the application stack: Raw HTTP requests are sanitized using OWASP ESAPI. Apache Shiro authenticates requests to ensure users have appropriate permissions to access the requested API resources. Data is then transferred into Data Transfer Object (DTO) beans, which are further validated using Hibernate Bean Validation. Finally, Elastic Path has a custom extensible validation framework that enforces business validation rules before the request is processed and any data is persisted.

All database access is controlled by Apache OpenJPA, which ensures that queries are parameterized and sanitized to eliminate the possibiliy of SQL injection vulnerabilities.

User Authentication and Password Storage

Cortex

All Cortex API requests must include an Authorization header that contains a valid access token. Any requests without a valid access token are rejected.

There are two ways that shoppers can acquire an access token:

• OAuth 2.0 Resource Owner Password Credentials
• OAuth 2.0 Authorization Code

OAuth 2.0 Resource Owner Password Credentials Grant Type

The OAuth 2.0 Resource Owner Password Credentials Grant is enabled by default.

To anonymously browse or checkout through the Cortex API, shoppers can request a public access token which provides limited API access. For more information about requesting a public access token, see OAuth2 Public Authentication.

To use the Cortex API in a logged-in context, shoppers can request a registered access token by providing their username and password. For more information about requesting a registered access token, see OAuth2 Authentication. By default, access tokens automatically expire after one week, but this is configurable. For more information, see the TokenExpiryResolverImpl class in the source.

To create a new account, shoppers can register using the registration API resource. Shoppers must first acquire a public access token before registering.

By default, passwords must be between eight and 255 characters in length, however this can be configured. For more information, see the @RegisteredCustomerPasswordNotBlankWithSize annotation on the Customer interface in the source.

Passwords are never stored in plain text. They are salted and hashed using BCrypt with a default strength of 8, which is configurable.

important

Higher strength values can have a negative impact on performance. For more information, see the passwordEncoder bean definition in service.xml file.

The change password and forgot password functionality is provided through the Tokenized Password Reset Accelerator. Shoppers provide their email address using the Forgot Password API, which emails a link to that address containing a secure token if a corresponding user record is found. Shoppers can use that secure token to update their password. Signed in users can also change their password through a separate API. Both APIs automatically invalidate any active access tokens when the password is successfully updated.

OAuth 2.0 Authorization Code Grant Type

The OAuth 2.0 Authorization Code Grant is enabled by the OpenID Connect Accelerator.

This method is intended to be used in combination with a third-party Identity Provider such as Okta or Auth0. In this flow, shopper credentials are never sent to the Cortex API. Instead, shoppers are re-directed to the Identity Provider for authentication. A generated authorization code is passed to Cortex, validated with the Identity Provider, and converted into an access token.

In this method, all password management is the responsibility of the Identity Provider, including forgotten or change passwords and email validation.

Commerce Manager

Business user authentication in Elastic Path Commerce Manager is supported through Spring Security. Users provide a username and password on the sign in page, and Spring Security manages a cookie-enabled session. Accounts are automatically locked if more than six incorrect passwords are submitted. This is configurable through the COMMERCE/APPSPECIFIC/RCP/accountLockoutThreshold setting. Users are automatically logged-out after 15 minutes of inactivity, which is configurable through the COMMERCE/APPSPECIFIC/RCP/idleTimeForLock setting.

Business users can change their own password through the Commerce Manager interface. By default, the following password requirements are enforced:

• Passwords must be longer than eight characters.

  note

  The minimum length is configurable in the COMMERCE/APPSPECIFIC/RCP/minimumPasswordLength setting.

• Passwords must contain at least one alphabetic and at least one numeric character.

• Passwords must be different than the previous four passwords.

  note

  The number of historical passwords the system can check is configurable in the COMMERCE/APPSPECIFIC/RCP/minimumPasswordLength setting.

Users with privileges can create new users, initiate a password reset for existing users, or disable existing users.

Passwords are never stored in plaintext. They are hashed using BCrypt with a default strength of 10, which you can configure.

note

Higher strength values can have a negative impact on performance. For more information, see the cmPasswordEncoder bean definition in service.xml file.

User Access Control

Cortex

Shoppers accessing the Cortex API with a valid access token are assigned an Elastic Path role that is based on the following elements:

• The type of access token, either PUBLIC or REGISTERED.
• The scope, which is the store code.
• The account the shopper is transacting on behalf of (if applicable).

This role is then transformed into a set of Apache Shiro roles which are used to determine which HTTP operations are permitted for a specific URI path. For more information, see the Cortex Authorization workflow documentation.

Commerce Manager

Business users can be assigned to roles that control access to areas of the Commerce Manager application. Additionally, users can be assigned to specific catalogs, stores, warehouses, and price lists that limit which records they can view and modify. More details about Commerce Manager user management and permissions can be found here.

Payment Data Security

Elastic Path Commerce contains a plugin framework for flexible integration with payment gateways. The framework allows each plugin to control which field values are collected and stored from the front-end.

The framework supports various payment operations including:

• Payment Instrument Creation Request
• Reservation
• Modify Reservation
• Cancel Reservation
• Charge
• Reverse Charge
• Credit

As a result, adherence to Payment Card Industry (PCI) rules is up to the payment plugin developers. However, the intent is for the front-end logic to post sensitive credit card details directly to the payment gateway in exchange for a token or nonce which can be safely stored in the Elastic Path Commerce back-end.

For more information, see the Elastic Path Commerce payment framework documentation.

Logging

Elastic Path Commerce uses the Apache Log4j and Logback frameworks for logging to both standard out and log files. Log levels can be configured to give extensive control over which details are logged. Only the most important events are logged at the INFO, WARN, and ERROR levels to avoid filling logs with information of limited value. All log statements are carefully reviewed to ensure that sensitive details such as credentials and payment information is never output through the logging framework.

Data Protection and Privacy

Elastic Path Commerce supports Data Policies which allow shoppers to give or revoke consent for Personally Identifiable Information (PII), and to automatically delete values when their retention periods expire.

Data policies can be used to maintain compliance with various data protection laws, such as CCPA (California Consumer Privacy Act) or GDPR (General Data Protection Regulation). The front-end can use data policies to present the customer with the option to provide or revoke consent for the collection of their data for business purposes.

Additionally, strict user access control rules enforced by Apache Shiro ensure that shoppers can never access information associated to another shopper (except in special Account Management scenarios, where it in intended).

Penetration Testing

Elastic Path uses a third-party vendor to conduct annual penetration testing on Elastic Path Commerce. This assessment consists of:

• Reconnaissance using Open-Source Intelligence Gathering (OSint).
• Probing identified ports and services to identify vulnerabilities that could lead to information disclosure and/or system compromise.
• Assessing the risk of identified vulnerabilities by attempting exploitation; and, prioritizing the vulnerabilities.

Resolution of identified vulnerabilities are prioritized and backported to all supported versions of the platform based on severity.

Deployment Security

Elastic Path does not define specific deployment options that customers must use. For more information about Elastic Path Commerce deployment options, see Elastic Path Commerce Deployment.

note

If you choose CloudOps for Kubernetes, the deployment security concerns discussed below are handled by that framework. For more information, see the CloudOps for Kubernetes Security Positioning documentation.

The following sections outline security concerns that should be addressed by your Elastic Path Commerce deployment tooling.

Trust Boundaries

Ensure that secure and insecure network are clearly documented and network requests within each of the zones are treated as trusted or untrusted. For example, communication between Elastic Path Commerce services and the database, message broker, and other Elastic Path Commerce services should be protected from unauthorized clients. This is so that any clients making requests within this zone can be assumed to be authorized. Encryption and authenticated access controls between these services is unnecessary, while any requests to endpoints at the edge of the insecure zone should always be encrypted and authenticated.

This approach allows deployment teams to limit the surface area that is susceptible to attacks. Within Cloud environments, load balancers and API gateways are normally used for SSL-termination and endpoint access control to enforce the secure network zone.

Endpoint Protection

In an Elastic Path Commerce environment, only the Cortex HTTP endpoints should be publicly accessible. All other endpoints, including the following, should be limited to trusted clients:

• JMX endpoints on all services
• Commerce Manager endpoints
• Search Server Solr APIs
• Integration Server APIs
• Database endpoints
• Message broker endpoints

Additionally, ensure that you block the Apache Felix Web Console at the cortex/system/console for access by public clients. If Cortex is being accessed through Javascript AJAX requests, the deployment tooling should add the appropriate Cross Origin Resource Sharing (CORS) headers to all Cortex API responses.

All public endpoints should be protected with a Web Application Firewall to protect from common security threats, and allow quick mitigation of zero-day vulnerabilities.

Business users should acquire access to Elastic Path Commerce Manager through one of the following ways:

• VPN connection
• Virtual Private Cloud (VPC)-peering
• Network IP tables

note

Users can only access network IP tables from authorized office IPs.

Similarly access by operations staff or back-end services that require access to Integration Server APIs should be limited by similar mechanisms.

Principle of Least Privilege

The Principle of Least Privilege states that a subject is given only those privileges needed for it to complete its task. If a subject does not need an access right, the subject should not have that right. This principle should be applied to all access accounts, including:

• Cloud access accounts, such as AWS Identity and Access Management (IAM).
• Operating system accounts
• Database accounts
• Deployment tooling accounts, such as Jenkins

Additionally, ensure that privilege escalation, such as sudo, is restricted to only accounts that require it, such as operations users.

Encryption of Data in Transit

Secure all publicly accessible HTTP endpoints with TLS 1.2 or later. This is done with a load balancer or API gateway act as a TLS termination proxy.

It is also strongly recommended that HTTP endpoints accessed by back-end services, such as Integration Server APIs, be secured with TLS.

Encryption of Data at Rest

Elastic Path Commerce supports many database technologies including MySQL, MySQL Relational Database System (RDS), MySQL Aurora, Oracle, and Oracle RDS. Regardless of the database technology used, ensure that any data recorded on persistent storage is encrypted. Also ensure that all backups, replicas, and snapshots are encrypted.

Vulnerability Scanning

We recommend using a vulnerability scanning tool for your deployment environment. These tools scan web applications for security vulnerabilities such as cross-site scripting, SQL injection, command injection, path traversal, and insecure server configurations.

Disaster Recovery

Elastic Path Commerce deployment tooling should give you the ability to quickly standup a new environment from scratch in case of an emergency. From a security perspective, this might include a suspected breach with unknown infrastructure modifications, a ransomware attack, or a malicious data manipulation scenario.

The most critical part of disaster recovery readiness is having automated, frequent database backups with point-in-time restore capabilities. Backups should also be encrypted in a secure zone to ensure that they don’t become a security vulnerability.

Production Security Checklist

Ensure that you complete the following security aspects when deploying to production:

• Apply all of the latest Elastic Path Commerce patches in the Elastic Path Commerce Changelog.
• Use certified external dependencies in the Elastic Path Commerce environment. For more information, see the Supported Technologies documentation.
• Disable the default admin and cmuser accounts in Elastic Path Commerce Manager.
• Change the default Apache Felix Web Console credentials. For more information, see the Configuring Felix security credentials documentation.
• Confirm that the Apache Felix Web Console at cortex/system/console is not accessible on public Cortex endpoints.
• Confirm that the following endpoints are not publicly accessible:
  • JMX endpoints on all services
  • Commerce Manager endpoints
  • Search Server Solr APIs
  • Integration Server APIs
  • Database endpoints
  • Message broker endpoints
• Confirm that database at rest encryption is enabled.
• Confirm that database backups are enabled and encrypted.