Ask HN: Can Jasmine Unit Tests Expose Security Vulnerabilities on Server?
Scenario: I'd like to set up Jasmine-standalone-2.0.0 front-end unit testing on the development server where I work. I'm a full stack dev but mostly front-end. I'll admit I'm not super security savvy.
A system admin is concerned that there will be security implications from 1. the Jasmine framework library being housed within the directory structure of a site build and 2. that having Some-SpecRunner.html files accessible by a browser could have security implications.Is anyone aware of security issues/vulnerabilities associated with the Jasmine Unit Testing Framework on dev servers or production servers? And if so any suggestions on how to best set Jasmine up to allay these concerns?
Thanks HN!
14 comments
[ 3.4 ms ] story [ 41.2 ms ] threadNormally, I run unit tests on my dev box; presumably your sysadmins don't care about that. I also run them on a special-purpose CI server. None of these machines are accessible to the outside world. I would never put the the unit test code in a place where it could be triggered by regular users or the general public.
Is that how you're setting it up? If so, what is the sysadmin worried about?
We don't have CI server. We have a dev server that is currently exposed to the world, our production server is separate. If Jasmine installed on the dev server a SpecRunner.html that triggers the unit tests on that dev server could be accessed by anyone if they knew the url.
This is what the sysadmin is concerned about. Would you say it's best to either 1. just run the unit tests locally as we don't have CI server set up or 2. Hide our dev server from the outside world and then it would be ok to run the unit tests on it?
Hope that helps to clarify?
There are a lot of reasons for that, but for me the two big reasons are good user experience and good security. You get a good user experience by carefully controlling what people see and making sure that's polished. You don't want to have to think about them stumbling across things that aren't for them. And good security requires minimal attack surface. You don't give naughty people anything to abuse that you don't have to.
What can be a problem: if you produce sample data during running the tests, you are going to produce a lot of trash data in your production environment. But you shouldn't do it anyway - just mock AJAX calls and so on.
Thanks for raising the trash data issue. The framework does a pretty good job of set up and tear down before and after each test is run, so I'm not too concerned about the trash data as it's destroyed once the test has completed. (If I'm understanding your point correctly?)