

Ask HN: Can Jasmine Unit Tests Expose Security Vulnerabilities on Server? - jbrowne

Scenario: I&#x27;d like to set up Jasmine-standalone-2.0.0 front-end unit testing on the development server where I work. I&#x27;m a full stack dev but mostly front-end. I&#x27;ll admit I&#x27;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&#x2F;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!
======
adambd
If I understand correctly what your question is, it shouldn't be a problem.
Since your JavaScript - which you are testing - is publicly accessible, the
tests shouldn't do any harm. They cannot do anythin, what the users couldn't
do anyways.

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.

~~~
jbrowne
Thanks for responding - that's my understanding too. Though if there's
something I'm not aware of, I'd love to know!

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?)

~~~
adambd
I mean something like you call a REST API where you create fake data which is
then visible on the production site. To avoid this, you should mock AJAX
calls.

~~~
jbrowne
Got it - thanks!

------
wpietri
I'm not quite understanding the problem.

Normally, 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?

~~~
jbrowne
Thanks for responding! Currently running Jasmine on local dev box, yes that's
cool, sysadmin not concerned about that.

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?

~~~
barylen
Your dev server shouldn't be accessible to the public. If you want a server to
be accessible to the public that isn't your production server (which is
valid), you should be doing things as similar to production as possible (not
running tests on it).

~~~
jbrowne
Thanks barylen for the response! Totally get what you're saying, could you
expand a bit on why?

~~~
wpietri
I agree with barylen. Dev should never be visible. For the general reason that
the default is "hidden". You make specific exceptions for the small number of
things you want people to see.

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.

~~~
jbrowne
That all stands to reason, thanks for the input wpietri.

------
staunch
You shouldn't be unit testing on production. You should run as little as
possible in prod.

~~~
jbrowne
Thanks for responding staunch! Is that mainly to avoid performance
costs/clutter, or for security reasons or both?

~~~
staunch
You're increasing risk for little benefit. A Javascript unit testing framework
could _likely_ be used for crafting XSS exploits. Or it could end up slowing
down real users when you forget to turn it off (or whatever). Probably nothing
bad will happen but it's a needless risk and a bad practice.

~~~
jbrowne
Ok, got it - makes sense. Thanks for the input staunch, much appreciated.

