Creating secure web forms starts with creating a secure website. This process is more complex than creating web pages and adding an SSL Certificate. A certificate is a solid first step, but it only goes so far as to protect whatever sensitive data necessitates security in the first place.

Naive attempts at security can ultimately make the data less secure and more likely to be compromised by creating an appetizing target for the unscrupulous.

So, what do you do beyond hiring a developer with significant security expertise? Start with this article. Its purpose is to shed light on many of the most significant factors in creating secure web forms and how to address them. At a minimum, reading this article will help you intelligently discuss website security with the developers you hire.

What Is Involved In Creating Secure Web Forms?

If you want to add a secure web form to your website, first, you must understand how to securely configure the website. Website security is a serious and complex topic; this article only discusses the high points. Check out some of our other articles and eBooks for more detailed information on website security.

Here are some of the critical issues that need to be considered:

1. SSL – Is the website and form secured to transmit data from the end user safely? Is your website form page protected with SSL to prevent tampering with its contents?
2. Web page content – Is the HTML content sent to the end-user protected from Cross-Site Scripting (XSS) issues, and does it avoid loading objects insecurely or from third parties?
3. Script Security – Are the scripts or programs that process the submitted data written with security in mind? Do they have any vulnerabilities?
4. Infrastructure – Is the website hosting provider trusted and known for good security? Are you on a shared server when you should be on a dedicated one?
5. Data Flows – What do you do with the data once submitted? Is that data secured?
6. Tracking – Do you track events such as data access and submission?
7. Archival and Backup – Are there processes to make backups and permanent archives of important data?

SSL – Web Security Starts Here

SSL certificates are required for creating a secure website and form. The SSL certificate allows:

1. The encryption of data sent to and from your web server and users to prevent eavesdropping or tampering.
2. Your users trust that they are connecting to your website securely.

An SSL certificates on a properly configured web server encrypts your website data as it flows to and from your end users.

To get an SSL certificate, you can order one directly from a third party, or your web hosting provider will handle it for you. In either case, the web host will need to install the certificate on the server where the website is hosted, and then you will need to make changes to your site to take full advantage of the secure channel you have added.

SSL and Encryption

The most significant reason people use SSL is to encrypt the data transmitted from their website and the end-user. When an end-user visits a page protected by SSL, their web browser communicates over a secure channel with the web server so that all data transmitted is sent over this encrypted channel. This helps prevent eavesdropping and man-in-the-middle attacks on the data (more on these below).

Without SSL encryption, there is little or no protection of the data.

SSL and Trust

The most overlooked and misunderstood aspect of SSL is the establishment of trust. That is, enabling your end-users to trust and feel confident that they are connecting to your website. What else could they be connecting to, you may ask?

1. Someone with access to the network between the end-user and website could be trying to intercept and read all the web traffic or altering your website pages themselves (e.g., changing your forms to submit the data to them instead of you). This is called a man-in-the-middle attack. Even with SSL security, a man-in-the-middle can present the end-user with an SSL Certificate for your domain name that looks legitimate, like a forged ID card.
2. The user could be visiting another website that is pretending to be yours. This phishing website could collect information from your users for malicious purposes. Unless your users identify this site as illegitimate, they could be duped into revealing personal information. How could they end up at a phishing website like this? This can happen by clicking on a link emailed to them or by visiting a misspelled version of your URL. No site is immune from such attacks, but you can work to mitigate them.

SSL Certificates and Cybersecurity

As mentioned above, SSL certificates are not the sole website and form security solution, but they can help! To understand how it’s worth looking at how certificates are awarded. SSL certificates are signed by a third-party authority, the “Certificate Authority.” This can be:

1. You, if you sign your certificates.
2. A respected third-party issuing:
   1. A cheap or free certificate validating only your domain.
   2. A more expensive “Extended Validation” certificate which also validates your organization.

If you sign your own certificates, your website will generate warnings when anyone visits it. Users can choose to dismiss them, but more commonly, they will be more likely to navigate away from the website. For this reason, self-signed certificates are never recommended for a public website. Self-signed certificates provide no inherent trust that they are legitimate (anyone can generate one and pose as your site). They look amateurish and are annoying to the end user. Self-signed certificates should only be used in internal or test environments.

When ordering a certificate from a trusted third-party authority, there are various types that you can order. The cheapest ones are called domain-validated certificates. These work by emailing your domain administrator a validation link. Once verified, the certificate is awarded. These domain-validated certificates are acceptable and provide excellent security; however, as no humans are directly involved in the validation process, it may be easier for an attacker to get an illegitimate certificate by gaining control of the admin’s inbox or via other methods.

You can also order Extended Validation certificates. They cost more because real people validate the organization and your domain ownership. They make phone calls and ensure that everything looks right. If you have one of these certificates, your browser’s address bar turns green (or displays a lock symbol) when visitors come there to indicate that this site is trusted. If you want to maximize trust and make it easy for your end-users to identify your site as legitimate, you should use an Extended Validation certificate. These cost more but are well worth it in terms of security and trust. If EV certificates are outside your budget, you should still use an SSL certificate from some trusted third party.

Securing Web Forms with SSL

Once your website has an SSL certificate installed by a web host, your web pages can be accessed with addresses that start with “https://” instead of just “http://.” The “s” in “https” means “secure.” Note:

1. When connected to a web page using a secure address like “https://yourdomain.com,” the web browser will show a lock icon to inform you that the connection is secure.
2. Web pages that end in “.shtml” are not necessarily secure. The “s” means “server” (i.e., server-parsed page) and not “secure.” So, for example, “http://yourdomain.com/index.shtml” is not a secure page, but “https://yourdomain.com/index.html” is a secure page.
3. With SSL enabled, you can access the same page securely and insecurely in many default web server configurations. Both “http://yourdomain.com/form.html” and “https://yourdomain.com/form.html” work and show the form — the only difference is the use of SSL or not.

So, let’s say that you have a web form located at “http://yourdomain.com/form.html.” You have an SSL certificate, and your web host has installed it. Next, you want to:

1. Make sure people connect securely to the form page.
2. Make sure that no one can connect to the form page insecurely.

These two goals might sound the same, but they are not.

Enforce Secure Connections to Form Pages

Since regular website pages may be insecure, you need to ensure that the links to the secure form page are absolute links starting with the prefix “https://.” This will ensure that anyone clicking these links will be taken to the form page on a secure connection.

The best solution is to use an HSTS (HTTP Strict Transport Security), which tells browsers that they should always use the secure version of your website. If you choose to have both the insecure (http) and secure (https) versions of your site running at the same time (not recommended), then you need to be careful with linking so that sensitive pages are secured:

Wrong Links: Relative links are not recommended because, if the user is on an insecure page, relative links will always take them to insecure versions of the destination page. So relative links like the following should be avoided:

Fill out my form!

Correct Links: Absolute links will ensure a secure connection by specifying that SSL must be used via the link prefix “https://.”

For example: <a href=”https://yourdomain.com/form.html”>Fill out my form!

Be sure that all links to all secure pages of the site use this secure format with the “https://” prefix.

Side Note: These days, it is recommended that you use SSL for all website pages, not just ones that process sensitive information. This is good for user trust, security, and privacy. It is also good for Search Engine Optimization (as Google will reward you for securing your site). If you set up your site so all pages are always secure, relative links are safe.

Ensure No One Can Connect to Form Pages Insecurely

Using the above suggestions, all the links on your website will take users to the secure version of the form. However, most web hosts leave the insecure version of the form there, and users can still access it if they enter the insecure address directly (or if links are directed to the insecure page). As a next step, you should ensure that accessing the form page via an insecure connection is impossible.

There are several different ways that this can be done. Some of these include:

Separate space for SSL pages: If your web host has this feature, you can configure the website to store web pages for secure (SSL) connections in a different directory from those for insecure pages. If this feature is enabled, the form page is placed in the secure directory and no copies are in the insecure directory. Thus, any insecure requests for these pages would result in a “page not found” error. You could then implement server-side redirection rules where if someone requests the insecure page, they are automatically redirected to the secure version (this can be done using .htaccess files and the “Redirect” directive). If you did this, secure and insecure requests for the page would take the user to the secure version with no errors, warnings, or issues for the end user.

Scripted pages: If the form page is generated by a server-side script (i.e., PHP, Perl, Python, or JAVA), then the script itself can determine if the request is secure or not (e.g., by looking at the server environment variables). For secure requests, it can render the form as usual. The user receives an error for insecure requests or is redirected to the proper secure location. 

Securing all pages: (Recommended) The site can be configured to automatically redirect all requests for insecure pages to the respective secure page. All pages will be secure, and any accidental/incorrect requests for the insecure pages will still get people to the right place. Security is greatly improved if you have set this up.

If my form is posted to a secure form processing script, why does it need to be secured?

This question is usually asked when a third-party manages the form processing. Is securing the form itself with SSL needed?

The answer is based on the following facts:

1. The data sent from end-users to the server will be secure and encrypted during transmission. This is critical for creating secure websites and forms that require HIPAA compliance.
2. Non-technical end-users will only know if their data is securely submitted once it is done. Many end-users will refrain from submitting sensitive data to an insecure form on your site.
3. End-users cannot know if they are viewing your website or a phishing site or if eavesdropping and modification are happening. Many users will not trust the connection and will not want to submit their data through your site if it appears insecure.
4. If your form page is insecure, it is straightforward for any malicious party to perform a man-in-the-middle attack to eavesdrop on connections, modify your form in transit to change what is collected and where the data is sent, and set up phishing sites. Your end-users can’t tell if this is going on.

If you do not secure your web form with SSL, it is vulnerable to attack. If nothing is going on, you can rely on transmission security. However, that minimal level of security is not recommended for production websites or anywhere that compliance is required.

Other Aspects of Creating Secure Web Forms

Proper use of SSL for encryption and trust is only part of creating secure website forms. You must be concerned with many other aspects to protect your users, your application, and your company’s reputation. These include (but are not limited to):

1. Cross-Site Scripting (XSS). Suppose you include dynamic content on your web pages (i.e., information submitted by other users or content submitted via form fields), and that content is not cleaned of JavaScript and HTML. In that case, bad actors could make arbitrary content appear on your website, capture user data, or worse. All data displayed should be clear of undesirable content (script tags, special characters, HTML, and other things). This is one of the most significant security issues with dynamic web pages across the internet.

2. Secure Server-Side Programming: The scripts and programs that accept and process the data from online forms must be created with security in mind. They must validate all submitted data as needed without making assumptions about its format and content. The scripts must not provide avenues for attacks like SQL Injection. Scripts must not use submitted content as actual filenames or URLs for remote loading content. They should log any strange errors or problems for later analysis. They should provide a mechanism for blocking undesirable actions or users from using the scripts.

3. Validation: Validation of all input data is part of the above two points. However, it is so essential that we will repeat it and go over some of the fundamental points:

• If you validate submitted content, always perform your validation on the server side. Even if you use JavaScript to validate the data on the client side, you should always re-validate it on the server side. Why? Because people can get around JavaScript and submit arbitrary content directly to your scripts. The scripts should be prepared to handle that.
• Always de-taint submitted data. What does that mean? It means never trust submitted data and take pains to ensure that the submitted data matches what you expect. For example, if you have a select list that sends your script a number as the value, do not assume you are getting a number. Instead, check that it is a numeric value or convert whatever is submitted into a number.
• Remove disallowed content from the text submitted by users. Remove or block special characters, embedded codes, and other things that should not be there.
• Ensure the submitted data is manageable enough to be used.
• Do not assume anything — program defensively.

4. Preserving State with Hidden Form Fields or Cookies: If your program remembers information from one page to another by saving the data in hidden form fields, then your program must also ensure that the content of those fields was not tampered with. One good way to do this is to make a hash of all the data, together with a secret value, and include that hash in the form data. Then, when the form is submitted, you can recompute the hash and compare it with what passed from the form. If they match, you are okay; if they do not, the data has been tampered with. No one can break this scheme without knowing your secret value or breaking your hashing algorithm. This method can also be used to validate data saved in cookies. You can go further and use time stamps to prevent replay attacks.

5. Third-Party Applications: If you install programs from third parties on your website, you must ensure there are no known security issues with these programs, and you must be sure to update these programs as soon as new versions are released. If you let your website languish with an older, vulnerable version of a program, it will become a target for hackers as they constantly search the internet for such websites. Your site will likely be hacked in these cases, possibly causing loss of business, deactivation of your website, and tarnishing your website’s reputation. Using a third-party application is easy, but you need to select a good one that places the burden of keeping it updated on you. An exception is using a third-party application hosted by the third party itself. In these cases, the third party ensures that the program is continuously updated with anything needed to address any security issues. The burden is on them and not you. If you choose a good, respectable vendor, you should have no problems.

All these things, and more, are critical to developing a secure web application.

Securing the Form Data After Submission

Ensuring that users’ data is transmitted securely to your web server is critical, as is ensuring that your application is secure and will not be hacked. To secure sensitive data, you must understand what happens to that data after your program receives it. Many people forget that transmitting the data from the web server may require just as much preparation as receiving it from their users in the first place.

In the following subsections, we will look at three different ways of saving and retrieving your users’ data. In each case, we will explain what is needed to secure the data in your systems.

Send Form Data via Email 

The most common action data processing scripts do is email the submitted data to the website owner’s email address. The website owner knows when there are new submissions by checking their email and can access the data immediately. Most people running websites check their email reasonably often, which integrates well with their business operations.

However, the standard ways of sending emails are entirely insecure. So, how can you use email while ensuring the data is secure and viewable only by the intended recipient?

1. Have your website script encrypt the data.
2. Send this encrypted data (or a link to download the encrypted data) to the intended viewers via regular email.

As the form data is encrypted within the email message, most insecurities inherent in email are obviated. You can also use secure third-party services to have your form data emailed to you securely without programming anything yourself.

Save the Submission in a Database

Many website owners like to save the submitted form data in a database (even if it is also emailed to someone). Why?

1. The data is saved online and potentially accessible from anywhere.
2. If the emailed copies of the data are lost, the copies in the database are still there.
3. The database can be accessed through a web browser with a suitable user interface.
4. The data is typically backed up and can be restored.

If storage in an online database is for you, then you need to:

1. Use encryption, like SSL or PGP, to ensure the data is securely stored in the database. Why? The contents of database tables are not encrypted or secure in general. Storing unencrypted data makes it available to anyone with access to the database or its backups.
2. Provide a user interface that allows you to access the database data. It must be secure, have robust access controls, and provide a means for decrypting the data.

The database option requires much work to make a secure and usable solution. For this reason, most small organizations do not end up using secure database storage for important form data.

Save the Data in Files

The file storage option is the “quick and dirty” alternative to secure database storage. Essentially, your program will:

1. Make a file containing the form data.
2. Encrypt that file using PGP or SSL.
3. Save that encrypted file in a directory on the web server that is not accessible from the website. Another option is to save it in an online file-sharing service.

Then, the website owners can log in to the web server using Secure FTP and download these files as needed. They can be decrypted locally when the data must be accessed. Other simpler data access mechanisms are available if the files are saved in an online file share.

This solution is secure and provides an excellent backup to securely emailed data.

Other Technical Tips for Creating Secure Website Forms

There are many other considerations in developing and maintaining a secure website and forms. It would be impossible to cover or even list them all. However, here are some more interesting and valuable tips.

Use Secure Cookies

If your secure site uses cookies for anything, set the “secure” cookie and the “httpOnly” flags. This will ensure that these cookies are never sent insecurely over the internet when the visitor arrives at any insecure pages of your website (they are not sent at all to insecure pages) and thus helps preserve the security of the contents of these secure cookies.

Prevent Form Spam

Form spam occurs when automated programs find your web forms and try to send spam through them. Form spam can result in hundreds or thousands of useless form posts daily. Once you start getting form spam, stopping it is a priority. There are two primary ways to help prevent spam:

1. CAPTCHA – This method requires end-users to read text embedded in an image and type that text successfully into a form field. The back-end program then validates this. Since most spam programs cannot read text embedded in images, it will successfully block almost all automated forms spam. However, CAPTCHA requires the users to perform one more step, which can be annoying.
2. JavaScript and Cookies – Most automated form spam programs do not process JavaScript or use cookies. If your web form requires JavaScript to submit the form successfully, bots cannot do this, and most form spam will be blocked. This method is less reliable than CAPTCHA but does not require any extra work from the end-user. Note that if you wish to use the JavaScript method, you must be sure that arbitrary submissions to the default action URL of your forms will never succeed—only submissions made after the execution of your custom JavaScript should succeed.

Minimize the Need for Trust

A good rule of thumb is to minimize the need to trust third parties and trust only the trustworthy.

1. If you do not trust your internal IT staff, do not host your web application on your servers or give them access to the server used.
2. If you do not trust the third-party hosting your website, encrypt the form data as soon as possible. This helps ensure that the data is not saved anywhere in plain text and is not backed up in plain text, thus minimizing your exposure to unauthorized people. Further, ensure that the private keys and passwords needed to decrypt the data are not stored on the web host’s servers.
3. Ensure that only authorized staff can access the submitted form data. Ideally, it should always be encrypted, and only authorized people should be able to decrypt it.

These are just a few obvious points. As you evaluate your web application and data flow, ask yourself, “Who can access the raw data and how?” at each stage. Are there stages where you are trusting people who should not be trusted?

Forced use of strong encryption in SSL

The strength of encryption used by SSL is a function of both the user’s web browser and the server. Even if your web server supports excellent encryption, like AES256, the user’s browser may choose a weaker level of encryption. Older versions of Internet Explorer are notable for choosing weaker encryption in the interest of speed.

You can modify your web server configuration so that only levels of encryption you approve can be used to access your site.

Use Two-Factor Authentication

Two-factor authentication is standard on very secure sites now. You require a password and something else (a code or token) to validate their identity. With both, the user can log in. Avoid using only SMS texting as the second factor, which is no longer considered secure.

Get Started Creating Secure Web Forms

Outsourcing your form hosting and processing can be the fastest and most cost-effective way to get started. LuxSci’s Secure Form was designed for security and compliance. Contact us today to learn more about protecting sensitive information online.