Safeguard Your Installation
YouTrack is developed with security in mind. We take great care to eliminate exposures to different types of attacks. We work with third-parties who scan YouTrack for vulnerabilities and perform penetration tests. When a security issue is discovered, we strive to address the problem in the next major version or bug-fix release.
The recommendations on this page are intended to help you keep your YouTrack data secure. These best practices can help you avoid pitfalls that leave your data vulnerable to theft, damage, or loss.
Document Your Setup
Documentation is an important part of your security plan. If your YouTrack administration changes hands, the new administrator shouldn't have to learn how the application is configured through trial and error. As you follow this guide to secure your YouTrack environment, make a note of each change and explain why you set it up the way you did. When done, collect your notes and add them to your information security policy documentation.
Stay Up To Date
Your YouTrack InCloud instance is always upgraded to the latest version of the product.
To prevent accidental disclosure, we usually restrict the visibility to issues that are classified as a Security Problem to members of the JetBrains team. You may see issues in the Security Problem section of our release notes, but this is by no means a comprehensive list of security-related issues that have been fixed in any given release.
Encrypt Local Copies of your Database
YouTrack stores passwords in the database as salted hashes. Each user's password is hashed with a different, randomized salt. The salted passwords are hashed using the SHA-256 cryptographic hash function.
The database itself, including attachments, is encrypted with the ChaCha20 algorithm. There are several major implementations of ChaCha20, including Google's selection of ChaCha20 as a replacement for RC4 in TLS and its inclusion in OpenSSH.
When you download copies of your database, the data (excluding passwords) is decrypted on the fly. If you export and store backup copies of your database, we recommend that you apply filesystem-level or full disc encryption to the machine that you use to store the data.
Restrict Cross-origin Requests
If you have integrations or web services that request data from outside your YouTrack domain, you can restrict access to specific origins. YouTrack supports cross-origin resource sharing, or CORS.
To protect your data from malicious attacks, create a fixed list of trusted origins that are allowed access. You can manage this list in the Resource Sharing section of the Global Settings page. For more information, see Resource Sharing.
Use Digital Certificates
All YouTrack InCloud instances use HTTPS to encrypt traffic between the server and web browser, including the transmission of login data. However, your connections to third-party services can use HTTP. When you enable an integration in YouTrack, you need to secure the data that is exchanged between YouTrack and the connected service. Obtain an SSL certificate for each external service and import the certificates into YouTrack.
You should import trusted SSL certificates for any external application that is integrated with YouTrack. For more information, see SSL Certificates.
You should also have an SSL keystore that identifies YouTrack as a client when it tries to connect to a third party. For more information, see SSL Keys.
The following integrations can be configured to establish a secure connection using SSL:
- Mailbox Integration
- TeamCity Integration
- VCS Integrations
- Zendesk Integration
- LDAP Auth Module
- Atlassian Jira Auth Module
You should also use a digital certificate to secure the connection to the SMTP server if you use an external mail server to send email notifications from YouTrack.
Require Two-factor Authentication
YouTrack supports two-factor authentication (2FA). Many of the third-party authentication modules that are supported in YouTrack also support 2FA. YouTrack lets you require 2FA for every member of your organization. Users can choose to protect their accounts with app-based or token-based 2FA.
With app-based 2FA, users must use an external app to generate an authentication code, which they must then enter when they log in with their password. This adds an extra layer of security. Even if a password is compromised, the malicious user cannot access the application without the authentication code from the external app.
With token-based 2FA, users pair their Hub account with a hardware device. Users must have this hardware device in their possession when they log in.
When you require 2FA for one or more groups, the information that is accessible to members of these groups is subject to an additional layer of protection. To learn how to enable this feature, see Require Two-factor Authentication.
Enforce a Password Policy
If you're using third-party services for authentication and don't require 2FA, you can't guarantee that every user sets it up. Or uses a strong password.
Here's what you do know:
Many users don't create unique passwords for each of their accounts.
Most passwords are extremely weak and easy to crack.
An attacker only has to guess one weak password to gain access to your system.
The Hub authentication module lets you ensure that users create passwords that keep your data safe. If you use this module to manage logins, we recommend that you set the Password Strength to Good or Very Strong. For more information, see Set a Password Policy.
Require Email Verification
Asking users to verify their email addresses ensures that your users confirm ownership of their accounts. This is especially important when you let users register their own accounts.
For installations that create user accounts from incoming email messages with the Mailbox Integration or tickets that are imported with the Zendesk Integration, the option to require email verification prevents users from registering accounts that can be used to gain unauthorized access to YouTrack and other applications in your business environment.
The option to require email verification is located on the General Settings page in YouTrack. For more information, see Global Settings.
The Hub authentication module lets users register their own accounts in YouTrack. If you allow self-registration, you should protect your instance from registration bots. These bots can consume resources and claim licenses that are intended for use by humans.
To block registration bots, enable reCAPTCHA in the Hub authentication module. For more information, see Hub Auth Module.
Throttle Failed Login Attempts
Throttling or rate limitation helps protect the application from brute-force attacks. The Hub authentication module has settings that let you apply rate limits to logins and requests to verify credentials. Rate limits are applied per IP address. Rate limits help slow down brute-force attacks by blocking new login requests for a short time following a series of consecutive login failures, so they keep your passwords safe.
These rate limits are applied all logins from any active authentication module. For more information, see Throttling by Login Settings.
Grant Permissions with Care
All of the operations in YouTrack are managed by a permission scheme. Permissions are assigned to a collection of roles, which are then granted to users and groups for a specific project. Users only have permission to perform the operations that are allowed for the role that they are assigned in each project.
If you are overly-generous with granting permissions, you expose your system to high risk from insider threats. It also gives external hackers access to sensitive data as soon as any of your accounts is compromised.
We recommend that you follow the principle of least privilege and only grant access to the information and resources that are absolutely necessary to perform the operations that are required for each user. Start small, then go bigger — but only with good reason. Follow these guidelines to prevent unnecessary access to sensitive data:
Grant as little access as necessary to new accounts, then add permissions if necessary.
Revoke access when it is no longer required.
Delete or ban unnecessary user accounts.
Avoid the auto-join groups option if user registration is enabled in the Hub authentication module.
Limit the permissions that are available to the Guest user account.
Grant roles with very limited permissions to the All Users and Registered Users groups.
Limit the number of users who are assigned roles in the Global project.
Use as few accounts with System Admin roles as possible and monitor their activity.
Secure the Default Administrator Account
You set the username and password for the default administrator account when you confirm the registration for your YouTrack InCloud instance. These credentials are assigned to the root user account. This account has permission to perform any operation in YouTrack.
One of the most common problems detected by risk and security audits is an administrator account that is not tied to a specific individual. You might be tempted to create a simple username and password combination and share the default administrator account with more than one administrator. Don't.
Shared accounts are often used to gain uncontrolled access to systems.
Audit events and logs are rendered useless when you cannot associate a change with a specific individual.
Administrator accounts have unlimited access and should use the strongest possible passwords.
Follow these guidelines to secure your default administrator account:
After initial setup, create personal user accounts for each administrator and grant them the required level of access. Administrators should use their own accounts to perform administrative tasks.
Limit the number of accounts with administrative access rights to the users who require this level of access.
Require that users with administrator privileges use strong passwords and change them periodically.
Revoke administrative access as soon as it is no longer required.
Manage ownership of the default administrator account carefully. If the user who is responsible for this account leaves your organization or is no longer responsible for the application, select another user to assume ownership and transfer this responsibility. If the previous administrator no longer requires access to YouTrack:
Use the Merge User operation to combine these two user accounts. For more information, see Merge User Accounts.
Remove the credentials for the previous administrator from the merged user account.
If the previous administrator still requires access to YouTrack in a non-administrative role:
Create a new user account for the previous administrator and grant the appropriate level of access to the account.
Use the Merge User operation as described above to transfer ownership of the default administrator account to the new administrator.
We associate the email address that was used to register your YouTrack InCloud instance with your subscription plan. If the user who registered your instance no longer manages the subscription, open a ticket with the YouTrack support team and provide the email address of the user who is now responsible for your instance.
Browse Audit Events
YouTrack provides tools that let you monitor your application for suspicious activity. The Audit Events page provides a list of events, targets, and authors for every event that is logged in YouTrack. These events are recorded every time an operation is applied to a target entity that is managed by the built-in Hub service. This includes changes that are applied to users, groups, projects, roles, auth modules, services, and resources, among others. You can filter the list to search for specific types of activity or download the events as a JSON file for further investigation.
You can browse the audit events and security logs to detect unusual activity or for troubleshooting. If you use external security information and event management software, consider importing the audit events JSON file for automated analysis.
Limit Access to Sensitive Information
If you store sensitive information in your issues, take extra efforts to make sure this data is secure.
Use dedicated projects to store issues that contain information that can be used to identify a person.
Make sure the users who have access to issues in this project understand the sensitivity of this information.
Restrict project access to the users who need to view and use this information.
Restrict the visibility of issues and comments to the group of users who have access to the project.
For issues that contain sensitive or confidential information, don't leave anything to chance. If you rely on users to set the visibility manually, someone is bound to forget.
Use workflows to set the visibility for issues and comments according to your security scheme. You can create and attach workflows that support the following common use cases:
Set issue visibility automatically when it is created in a project that is used to manage sensitive information.
Change visibility when an issue is assigned a specific type or subsystem.
Warn users who set the visibility for a comment that is different from the issue visibility.
Block users from changing the visibility setting for an issue or comment.
For more information, see Workflows.
Restrict Anonymous Access
All YouTrack instances include a dedicated user account for guests. The guest user account is banned by default, but the access rights for the account are preconfigured. This user is granted the default Observer role in the Global project. If the guest account is enabled in its preconfigured state, anyone who knows your instance URL can use the guest account to browse issues in all of your projects without having to log in.
If you wish to limit or block anonymous access, you have the following options:
You can revoke the role that is assigned to the guest account in the Global project. You can then choose whether you want to grant the guest account an Observer role in the projects that you want to make available to the public. We generally discourage granting roles with update permissions to the guest account, as these actions cannot be associated with an individual.
You can continue to ban the guest account. If you leave this account as banned by default, all users are required to log in to view issues with a registered account. Access to issues in each project is determined by the roles that are assigned on a per-user or per-group basis.
For more information, see Manage the Guest User Account.