Secure data

Data security involves the protection of your organization’s data, any data that you host for customers, and any input entered by users during interactions with the product.

Secure data in motion

With P4 Code Review, you can secure data in motion by encrypting communications between P4 Code Review and users, and between P4 Code Review and the P4 Server.

P4 Code Review is typically deployed behind a web server (such as Apache or nginx) that is configured to serve content over HTTPS, so that web and API traffic is encrypted using Transport Layer Security (TLS). In terms of accessing P4 Code Review by using the web browser versus the API, P4 Code Review responses are consistent across the web browser and API.

Communication between P4 Code Review and the P4 Server is secured by encrypting the data in transit. By default, TLS 1.2 is used on the P4 Server, and TLS 1.2 or 1.3 is supported by P4 Code Review when connecting to the server. For instructions about setting up encrypted communications between P4 Code Review and P4 Server, see SSL/TLS connections between client and server.

TLS is the successor to Secure Sockets Layer (SSL), which is now deprecated.

Follow these guidelines:

  • If a P4 Server is configured to use TLS, all P4 Server applications, including P4 Code Review, must be configured to use TLS.

  • To enhance the security of your P4 Code Review installation, enable HTTPs encryption, as described in HTTPS. (If you integrate Slack or Jira with P4 Code Review, note that these services use HTTPS by default to communicate securely.)

  • If users access P4 Code Review and P4 Authentication Service (P4 AS) from remote locations, consider requiring the use of a virtual private network (VPN) to add an additional layer of encryption for data in motion.

  • If you are integrating P4 AS with P4 Code Review, ensure that both P4 Code Review and P4 AS are configured to use SSL/TLS. In this way, you can encrypt all data transmitted between the services. Obtain SSL/TLS certificates from a trusted Certificate Authority (CA).

  • For local communication, for example, between P4 Code Review and a Redis database, traffic is not encrypted. To help prevent unauthorized access, implement a firewall and VPN.

Secure data at rest

Securing data at rest involves protecting data on physical media, such as hard drives and solid-state drives (SSDs), and on cloud storage. Common methods include encryption, access controls, authentication mechanisms, and security audits.

P4 Code Review keeps its metadata in P4 Server’s built-in key-value store, accessible via the p4 key command. Security for this data is managed according to the guidelines in Secure the server.

P4 Code Review uses Redis as a cache. By using an encrypted volume for the Redis cache, you can help to secure the data at rest. Similarly, data transmitted between P4 Code Review and P4 Cloud is not encrypted by default. You can help to secure the data by using encrypted volumes.

Data specific to P4 Code Review and its related components is stored on the machine where these components are installed. To secure this data, access to the machine should be restricted and controlled including physical and network access, to prevent unauthorized access and potential breaches. To secure data at rest, you can add a layer of security by using an encrypted disk.

P4 Code Review enforces access control by delegating user authentication to the P4 Server, which supports multiple authentication methods. These include native Perforce accounts, where administrators can enforce strong password policies such as minimum length, complexity, expiration, and lockout rules. P4 Code Review can also be configured to use SAML-based single sign-on (SSO) through P4 AS, enabling centralized identity management and support for multifactor authentication.

Cookies are protected by secure headers. The headers protect data by controlling how cookies are sent, received, and used. Key headers include the Secure flag, ensuring that cookies are sent over HTTPS; HttpOnly, preventing JavaScript access to cookies to reduce Cross-Site Scripting (XSS) risks; and SameSite, limiting cross-site requests to prevent Cross-Site Request Forgery (CSRF) attacks. The Strict-Transport-Security (HSTS) header enforces HTTPS for all communication, and the Content-Security-Policy (CSP) helps to prevent XSS by controlling content sources. Together, these measures secure cookies in transit, and encryption safeguards sensitive data at rest. For details, see Security.

Secure user input

In P4 Code Review, user input is secured by hiding the content of input fields to prevent unauthorized individuals from viewing sensitive information.

Passwords are either not displayed or written as asterisks. In addition, to prevent unauthorized users from guessing passwords, the password fields do not have an autocomplete function.