Skip to content
  • ZipCode Api
  • Blog
  • About RedLine13
RedLine13
RedLine13
Primary Navigation Menu
Menu
  • Start Testing
  • Demo
  • Pricing
  • JMeter
  • Partners
  • Docs
    • Documentation Home
    • AWS Set Up for load testing
    • AWS Approval for Large Tests
    • PHP, NodeJS, Python Load Tests
    • Scalability
    • Jenkins Plugin Setup
    • Premium Features
    • Knowledge Base

Protecting Sensitive Data in JMeter Load Tests

By: David Koziel

One of the primary functions of a load test is to vet target test applications to see how well they can hold up to production conditions. In that endeavor it is sometimes necessary to provide login credentials and other protected information to be used in conjunction with these tests. This can present a challenge in protecting sensitive data when load testing in the cloud. In this post, we will cover how to test with JMeter in the cloud using sensitive data.

How to test with JMeter in the Cloud with Sensitive Data

What Constitutes Sensitive Data?

Any form of login credentials, access keys, or tokens meets the definition of sensitive data. Furthermore, source data such as CSV or other data files included in your test can also be considered sensitive data depending on the content. Your test results (depending on what information is captured) can also fall under this category. Thankfully RedLine13 has provisions to keep all of this information private and protected.

How to Secure Sensitive Data on RedLine13

We offer several ways to protect sensitive data within your JMeter load tests, but the common principle to these is separation of your data in a secure storage technology. In a previous post, we reviewed how to set up Remote Sources in your RedLine13 account. Once this is set up, you can reference Extra Files attachments that exist in AWS S3 or remote Git repositories. Here is an example of how that might be configured for a CSV file attachment:

Setting a secured path for JMeter test resources within RedLine13

Another way this might be utilized is as a credential store. For instance, you may need access tokens to a third party service (such as Azure Cloud Storage). Using remote sources, you can securely store access credentials or tokens to these third party resources. This would also be considered a best practice security approach, as access can be modified or revoked independent of your JMeter test plan file.

Following Security Best Practices

Any sensitive data is only as secure as the weakest link in its chain of protections. While not a comprehensive list, it is advisable that you follow at least the following best security practices for any sensitive data included in your tests:

  • Never store access credentials in plain text – This applies to storing access credentials in your test plan, especially usernames and passwords. Whenever possible, utilize a modern encryption standard such as AES.
  • Use tokens when possible in place of usernames and passwords – Access tokens can be longer and more complex than simple passwords. This makes them less likely to be guessed by an adversarial party. They can often be more specific to the task at hand and more easily revoked.
  • Employ layers of separation – Aim to store sensitive access credentials in a separate location from your test logic whenever possible. This will make it more difficult for your sensitive resources to be compromised.
  • Use the principle of least privilege – Only grant the privileges necessary to complete the task at hand. Administrator or level or broad access is hardly ever required from the perspective of a single load test.
  • Utilize access credentials which expire – Tests have finite lifespans, therefore it is prudent to set a finite time limit on access credentials used during a test. Often only the results of a test need to be accessed in the future, therefore short credential lifetimes are usually preferred.
  • Rotate access credentials regularly – To prevent old access credentials from being reused for other than their original intended purpose, rotate access credentials regularly.

Additional security best practices can also be found under various NIST publications.

Keeping RedLine13 Results Secure

By default, your test results are protected by your RedLine13 account credentials. Your test results will never be published or made available without your permission. You can however share your test results with interested parties by generating a link from our platform. If you decided to store sensitive data inside your test plan, this could potentially compromise that data. However, using the remote sources approach as described above, your data can be protected by one or more additional layers of security conformant to industry standard best security practices.


Did you know that RedLine13 offers a full-featured free trial? Sign up now and start testing today!

2023-05-03
Previous Post: A Guide to JMeter Preprocessors and Postprocessors
Next Post: RedLine13 Security Updates For Enterprise Users

Recent Posts

  • Order of Elements in JMeter
  • The JMeter Synthesis Report
  • Using the JMeter Plugins Manager
  • JMeter Rotating JTL Listener
  • Using Test Fragments in JMeter Tests

Related

  • Order of Elements in JMeter
  • The JMeter Synthesis Report
  • Using the JMeter Plugins Manager
  • JMeter Rotating JTL Listener
  • Using Test Fragments in JMeter Tests
  • Step-by-Step Guide to Testing with JMeter
  • Functional Testing vs Performance Testing
  • A Gentle Introduction to Load Testing
  • Using the JMeter Counter Element
  • Getting a “Grounded” Test to Launch

© RedLine13, LLC | Privacy Policy | Contract
Contact Us: info@redline13.com

Designed using Responsive Brix. Powered by WordPress.