1. Home
  2. Docs
  3. Administrator’s Guide
  4. Security


Considering that the data handled by GUARDARA is sensitive in nature, a dedicated page documenting the security features and, in certain cases, the lack of those and related risks can help customers to protect their deployment better.


Access to GUARDARA requires password-based authentication. GUARDARA stores passwords in a non-reversible form (salted hash) to protect credentials in case of unauthorized access to the database. The only password complexity requirement in place is that all passwords have to be at least eight (8) characters long. The Business/Enterprise edition of GUARDARA allows customising the password length requirements.

Not having support for traditional (old-school) password complexity and password rotation rules was intentional and we have no future plans for such features. Instead, we recommend following industry best practices and choosing a strong passphrase. For further reading on this topic, click here.

To further protect accounts, users can enable two-factor authentication (2FA). The Business/Enterprise edition of GUARDARA allows enforcing 2FA globally.

Session Variables

It is not recommended to store sensitive information in Session Variables defined within Message and Test Flow templates as:

  • Session variables are not encrypted
  • At the moment, there is no concept of data ownership (see next section)
  • There is no database-level encryption

In case testing with GUARDARA requires sensitive information such as credentials to be stored in Session Variables, it is recommended that:

  • The credentials are explicitly created for testing with GUARDARA
  • Such credentials do not provide access to production systems, or to systems other than the test target
  • The account the test credentials belong to has no access to production data


Callback templates allow running arbitrary Python code on the Engines during test runs as part of the test flow. Therefore, it is important to ensure that only trusted personnel is able to create callbacks or create or modify Flow templates.

Make sure to carefully review any Python code in Callbacks that came from untrusted sources.

Data Ownership

Any data managed by GUARDARA, such as templates, projects, and reports are accessible to all users with the appropriate role. For example, a user with a role that allows reading reports can read any reports, even those that were produced by a test run of another user.

While data ownership related improvements are on the roadmap, for now, it is recommended to use the role-based access control to configure who can or cannot access certain types of information.

Data Encryption

There is no database-level nor application-level encryption implemented. Any data managed by GUARDARA is stored as clear-text; this includes, for example, the SMTP server credentials too. What this means is, if the hard drives of the machine running GUARDARA get stolen, the malicious actors could gain access to the data. In environments where this risk is applicable, it is highly recommended to utilize full disk encryption.


Extensions allow extending the capabilities of GUARDARA, and they are an integral part of the ecosystem. However, deploying malicious extensions can lead to unauthorized access to the systems running Engines. The impact of a successful attack is higher in case an Engine is running on the same host as the Manager because a compromise would provide an attacker access to the system that handles all data.

Because of the above, GUARDARA requires all extensions to be cryptographically signed. This signature is validated during deployment to ensure only extensions coming from a trusted source are deployed. To further mitigate the risk, it is also recommended not to run Engines on the same host as the Manager.


The certificates used by GUARDARA are issued by GUARDARA’s own certificate authority, the rootca microservice. Certificates issued by this service is used both:

  • Service-to-service: Authentication between microservices is done by validating the client certificate. If the certificate was issued by the rootca, only then the connection will be allowed.
  • User-to-service: By default, the Manager uses a server certificate issued by the rootca.

In case of unauthorized access to the rootca service, an attacker could obtain a certificate that allows communicating with any of the microservices. Also, in case an attacker managed to steal the client certificate of a service, the certificate could potentially allow the attacker to connect to certain microservices.

Even though the rootca is bound to listen on the loopback interface only (, anyone with access to the machine running the microservice could obtain certificates as the rootca service requires no authentication.

As per the above, it is highly recommended to restrict access to the system running the rootca microservice.

Reporting Security Issues

Should you find any security issues please report them via info@guardara.com.

Was this article helpful to you? Yes No