If the application is not in production mode, there is no commercial contract signed with customer yet, and you just want to give a link to the customer (or give the demo yourself) so that they can experience the app themselves, then how important is it to use HTTPS enabled server?

SSL certificate comes with a cost, so deploying them for only demo or pre-production server may not be commercially viable for most solution providers. So, please let me know how critical is to use HTTPS enabled server even if the data is only demo data and no contract has been signed.

Edit: Application requires login, so no one can see data without login

  • 1
    startssl.com = free ssl cert. Only takes time, and can only be used with 1 sub-domain per certificate (but you can make many certificates... or pay for a wildcard)
    – WernerCD
    Commented Jul 12, 2013 at 14:14
  • 1
    Answers handle demo servers well, I will comment on pre-production servers: I would make pre-production servers are similar to production servers as possible, to increase the probability of something working on a pre-production server also working on a production server.
    – Matt
    Commented Jul 12, 2013 at 14:19
  • 1
    @gurvinder372 The cheapest commercial SSL certificates cost $10 or less. Is this really ever an issue?
    – Joel
    Commented Jul 12, 2013 at 15:03

6 Answers 6


It depends on your specific case. How valuable the demo data is, how security-critical the product is, and the probability of an attack during the demo. So I'll give you my personal opinion.

The general public has become more informed about SSL in the past few years. Everybody knows about checking for the "S" or checking for the padlock, so chances are that your customer already knows about HTTPS. Your customer might think "Why aren't they using the padlock? Does it mean this product is not secure?". Using self-signed certificates will show the big scary warning and will make you look unprofessional.

For those reasons, go with HTTPS. Besides, StartCom offers free SSL certificates, and Comodo offers a 90-day free trial.

  • 1
    Good point on the free trial certs; that is a handy way to demo secure pages on a short-term basis. It's also good for testing, since changing over to HTTPS may require a bit of extra dev time and you can knock this out during your beta phase. Commented Jul 12, 2013 at 9:04
  • +1 for "It depends on your specific case." You need to do a risk analysis on the data and the application. If there are material risks that can be reasonably mitigated via the use of HTTPS, use HTTPS. If not, then don't.
    – Xander
    Commented Jul 12, 2013 at 13:12
  • Arguably usually there is no reason not to use HTTPS - encryption is relatively cheap nowadays (in terms of computational power). My feeling is that one should use it unless there is specific reason not to (and no HTTP means that no data will be disclosed by accident later on). Commented Jul 12, 2013 at 14:27

I think it is a good idea to protect even a test application with SSL and use a certificate from an "official" CA.

This is because most customers don't distinguish between your application and the protocol used to access your application. They simply think: "Well that's a fine application but my data is unprotected".

IT people can distinguish between this so for them it looks like: "Well this is a fine application and switching on SSL should be easy".

So when yor customers don't have any IT background use a certificate even for your demo application.


I am afraid I am going to have to disagree with @Gurzo.

It is pretty critical: not necessarily for a security standpoint per se, but because of the better reputation on having the right attitude towards security. Your site will be setting an example by showing interest in keeping things secure, on every circumstance. It does not really matter the data is demo only: if someone steals someone else's data, including credentials, and publish this information, this will inexorably affect the reputation of your site/company.

Having said that, I know that in the end, it all depends on money and overhead, and I get the feeling of not wanting to implement SSL certificates, however, at this point, I agree with @Adnan in saying that the answer to "how critical it is to implement HTTPS on demo site" depends on your circumstance. Use a free certificate. Or, I would even risk saying that, though a self-signed certificate might make your site look unprofessional, you can always put a note saying that it is for the sake of good security policy, which shows mature attitude towards security, balancing out the unprofessional look of the ugly error message. To reinforce this argument even further, I shall quote @Thomas Pornin - whose credibility is undoubtedly irrefutable - in this answer, where he says that:

"[...] in many situations, SSL with a self-signed certificate is much better than no SSL at all."

I know his answer was for a different context; but the bottom line is that if you are not gaining any extra good reputation for having SSL enabled, you can quite safely conclude that you will definitely not be getting any bad reputation for not being security-aware.


First of all, let's remember that HTTPS provides authentication for the web server and encryption for the data sent between the client and the server.

Since the exposed application is a demo version, it probably requires demo credentials and contains demo information. Hence, since no critical data is exchanged between the client and the server at any point during the user activity, there is no need to employ HTTPS.


Plenty of reasons to employee HTTPS.

  • Practice makes pefect.
  • Train like you will deploy
  • Someone not noticing the Green Lock is much better than someone noticing lack of security
  • You want to demo secure/best practices that will be used in the real application
  • Demonstrates the application in the same environment as deployment
  • Demonstrates attention to detail

Demo account, demo data, etc... the data probably isn't worth the protection but your showing off your application, skills, work ethic, etc. Show your best side with ALL the bells and whistles.

Vince Boudreau: If a man builds a thousand bridges and sucks one dick, they don't call him a bridge-builder... they call him a cocksucker.

-Play it to the Bone (1999), Woody Harrelson

You can do a million things right... but you will be known for the one thing you do wrong. Look at President Clinton. Leader of the Free world at one point, and all he's really known for is a blow job.

A lack of a lock shouldn't be world ending, but you don't want to be known for insecure products.

Plenty of places to get free certificates as well. Startssl.com is one that I continue to use.


Imperative! Just as you, a developer, will want to be involved with the client's project early on, so will the potential attacker. Additionally, it's a convenient vehicle to communicate to your future clients your competence and recognition that security matters. Ideally, you'd want to throw at your back-end as many protection mechanisms as there will be in use in production. Not just to ensure the transport layer security (HTTPS), but also keep verbose access logs, run a Web Application Firewall (or similar technology), keep as tight control over who is having access to what, and more. I'll get to the other parts later, but let's first discuss the need for a SSL/TLS certificate.

There are two major points to having your web server HTTPS enabled:

  • First one is to ensure trust of the end user he's indeed connecting to the right web server and is not being a victim of social engineering attacks by an attacker staging a spoofed (or phishing) location where he's running a partial or a complete copy of your demo website for the purpose of collecting user credentials, or other sensitive user data. Phishing location needs not be complete, but merely limit it's functionality to, for example, presenting a fake user sign-in page, recording entered data, and repeating HTTP POST sign-in request to the real web server, so the victim doesn't suspect a thing.

  • The second one is that it enables transport layer security by means of encrypting transmitted and received HTTPS request and response data, effectively preventing a Man-in-the-middle (or MiTM) attacks by means of snooping on data packets and their contents, exchanged between the client and the server. Attacker, finding himself in the position to be able to listen on this communication (say, your demo client is connecting through a public access point, or other untrusted connection), record exchanged confidential information and thus collect user credentials. Attacker is also capable of changing contents of exchanged data packets, but let that be irrelevant here, since it's not really required to stir enough trouble without it as well.

There are of course other, less critical benefits to using HTTPS, such as the client not repeating request GET data (URLs) to another web server in referer HTTP header field, but let's, for the sake of brevity, limit ourselves to the first two benefits regarding use of HTTPS and dangers of running even a demo setup without it;

So the would-be attacker could gain demo client credentials. You'd now naturally ask, what's the big deal? Well, this greatly depends on the way you create these demo clients (whether you're sending them random user credentials they can use to sign-in, or let your demo users choose their own passwords), and what access is such demo user granted upon signing-in. Regardless, the attacker could learn a great deal about the inner workings of your web application (means of accessing confidential information, data structure, website structure, CMS location, and even means of editing user data), follow your progress in thwarting against potential threats, inspect for vulnerabilities you might have unwittingly left open, and use that to his advantage later on, on any production servers you might obtain contract for. And heavens forbid, if you let your demo users use their own passwords, some of these might even repeat on production servers, or users might use them to access other accounts. Needless to say, this could potentially spell disaster both for you, as well as your potential clients.

To thwart against such threats, you would want your demo server to be as secure as your production server. This will also present an opportunity for your demo clients to test your solution's suitability, communicate required changes to it, and generally improve your odds you will be selected as the solution provider / developer. This is especially true, where security related certification is required before deployment, for example in the financial or healthcare sectors. I'm going to repeat some of the obvious recommendations, and add a few more as I go:

  • Make sure you're creating demo accounts on your own, assigning them random and utterly meaningless passwords, and you don't let your demo users choose their own. Clearly visually notify the user, he's using a demo web application, to avoid them entering production passwords by mistake. Keep a tight control over who receives which sign-in credentials, and only ever send demo passwords via secured channels, preferably in person. You could print out a few dozen business cards with these demo credentials at their back, give them to your potential clients in person, and write down who received which demo account. Require password change upon user's first signing-in, and display clearly written security warnings, such as their newly chosen password shouldn't be same as they use for any other services.

  • Track user activity by enabling verbose logging, throw in a well configured WAF for good measure, and regularly check their logs for suspicious user activity (network scanners, fuzzers, brute-force attempts, illegal sign-in credentials used,...). Promptly block any offending IPs, or disable a demo user account and send out new credentials, if needed. Protect access logs and other statistical data from unauthorized access both remotely as well as locally. Don't log any personal information or user credentials, and use encryption and/or password hashing wherever applicable.

  • Make sure you use this fact that you're properly protecting access to your demo server also to your advantage with the potential customer. Build on their trust that you know what you're doing, that while this demo access might be less convenient, it's there for good reasons, and to protect both of your investments. Train your sales personnel accordingly.

In short, don't provide for a would-be attacker a test platform and a convenient overview of your built-in protection mechanisms. If you can't afford a SSL certificate for each demo server you set up (even if you can get them for free, it will involve work to set servers up), then host them on the same location and distinguish between demo clients based on their credentials. Don't use a self-signed certificate, not to give your potential customers wrong impressions that you're disregarding usability and end user convenience, and to also avoid other threat vectors. Use the fact that you're serious about protecting your clients to your advantage during sales. Constantly test your web application and server security, and follow latest developments in the IT security arena.

You must log in to answer this question.

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