I am writing automated tests for a web application that will be run periodically over night, and I am running into a moderate security issue.

In order to make the tests thorough, I am hoping to include live data as test input rather than relying exclusively on mock data generated specifically for these tests (this would ideally make the testing substantially more robust). However this is challenging because these tests are stored on a public (to my company) Git server and need to be universally accessible. However not all employees have permissions to view the live data that is used in these tests. As a result I am trying to come up with a way to hide this live data such that it can be used at runtime by automation (in this case RobotFramework running Selenium), but cannot be viewed/accessed by a user pulling down the containing Git repository.

I was hoping to encrypt the stored data and only decrypt it at runtime of test automation. However, this would require providing the test automation suite with credentials to decrypt the encrypted data, which defeats the purpose of encryption in the first place. These automated tests will need to be run automatically over night, which precludes having a human user enter the password to decrypt data.

As a result, I am wondering if what I am trying to do is conceptually possible and how I might go about doing so. My best thought is perhaps finding a way of providing decryption credentials to the job agent that runs the tests, but this is logistically complicated (and the bob agent itself might also need to be publicly accessible) and I am curious if there is another way.

I am not an expert in security (although I understand basics) and so any suggestions are welcome.


1 Answer 1


That's a bit unfortunate.

So long as your code and testing framework are both public, there's nothing that you can do that your unauthorized users can't. You need to lock something down.

The best this I can think of is to put the data on the server running your tests. Limit access to the server to only authorized individuals. That way even if people find the server information, they won't have access to pull the data from it.

  • Interesting, that is definitely unfortunate but definitely good to know. Maybe what I can do is store the password in/on the job scheduler and then restrict access to that, which is basically what you're suggesting. Thanks.
    – UpQuark
    Sep 29, 2014 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .