1

This is a very generic question that popped up in my mind. The reason has been that I came across a website dev server which leaked sensitive information about a database connection due an error. I was stunned at first and now I wonder why someone puts a development server out in the internet and make it accessible to everyone?

For me there is no reason for doing this.

But it certainly did not happen by accident that a company created a subdomain (dev.example.com) and pushed development code to it. So what could be the reason to ignore the fact of high security risk?

A quick search did not bring up any information about this. I'm interested in any further readings about this specific topic.

Thank you in advance

roccosportal.com
  • 136
  • 1
  • 8
  • Are you sure it was a development server. It wasn't a preview/UAT server? – Ron Deijkers Aug 01 '13 at 09:32
  • No, I am not sure. But the exception triggers when calling a certain webpage and not after doing some fancy stuff. I would claim that a preview/UAT server should have been tested at least before or right after going live. (Testing after going live is important here, because the error occurs due a misconfiguration). – roccosportal.com Aug 01 '13 at 09:43
  • I absolutely agree. Ofcourse a UAT should be well tested. But to answer your question, to there is absolutely nothing I could think of that would make it useful to have a development environment exposed to the internet. – Ron Deijkers Aug 01 '13 at 11:41

2 Answers2

1

There is no reason for your dev servers to be accessible by the general public.

As a customer I just had an experience with a private chef site where I spent time interacting with their dev server because it managed to get crawled by Bing. Everything was the same as the live site but I got increasingly frustrated because paying a deposit failed to authorise. The customer support team had no idea I was on the wrong site either. The only difference was the URL. My e-mail address is now in their test system sending me spam every night when they do a test run.

Some options for you to consider, assuming you don't want to change the code on the page:

  • IP Whitelisting is the bare minimum
  • Have a separate login page that devs can use that redirects to the dev site with the correct auth token - bonus points for telling stray users that this is a test side and the live site is at https://.....
  • Use a robots.txt to make sure you don't get indexed
  • Hide it all behind a VNET - this really isn't an issue anymore with VPNs or services like Bastion.

Also consider the following so your devs/testers don't accidentally use the wrong site:

  • Have a dev css to make it obvious its a test system (this assumes you do visual testing later in your pipeline)
  • Use a banner to make it clear this is a dev site

Note that this would be a dev server. If you are using ringed/preview/progressive deployment then these should work just as well as the live site because they are the live site.

James
  • 433
  • 4
  • 14
-4

It's extremely common for a development environment or any "lower level" environment for that matter to be exposed to the pubic internet. Today, especially with more and more companies working in the public cloud and having remote team members, it's extremely more productive to have your development team or UAT done without having the need to set up a VPN connection or a faster more expensive direct connections to the cloud from your company's on premise network. It's important to mention that exposing to the public internet does not mean that you shouldn't have some kind of HTTP Authentication in these environments that hides the details of your website. You can also use a firewall with an IP address whitelist. This is still very important so you don't expose your product and lose a possible competitive advantage. It's also important because lower level environments tend to be more error prone and important details about the inner workings of your application may accidentally show up.

Dave Arlin
  • 39
  • 4
  • 1
    No, dev servers should not be accessible to the public internet. This comment acknowledges that lower-level environments are error-prone and may show the interworkings of a system, but still recommends having the application public as "extremely more productive". It's absolutely irresponsible. – david Dec 09 '19 at 18:07
  • @david - I wish it didn't take me a year to see this snarky response. Clearly you missed the part about requiring auth or having allowing some IPs through the firewall. Seeing a stack-trace in a Dev environment is all par for the course for the development team. What if your Production environment is being exposed to the internet, the idea would be that that needs to be quite secure and require some kind of auth. Either way, most modern frameworks have ways to quickly change a config setting to show stack traces vs a custom error page. Exposing to the internet doesn't mean accessible. – Dave Arlin Dec 17 '20 at 02:48