Don’t Forget to Consider Security When Building Your Web Site – Part 2

Last week, we began the discussion about how you can take safeguards today to protect your web site and its content from the bad guys.  This week, we get a bit more technical  by discussing  4 more safeguards that your web developer can verify or implement right away to help keep the bad guys from wreaking havoc to your web site and its sensitive data.

Use Custom Error Pages to prevent the real cause for a web site error from displaying in the visitor’s web browser

The bad guys use error messages to gain insight into your web site, including the type of web server, the database that you’re using, and potentially more scary, the tables and fields in your database. Once they have that information, gaining access to your site’s information to them becomes child’s play.  Having custom error pages not just for missing pages, but for ones that are generated because of errors makes it much harder for the bad guys to do terrible things with your web site and its data.

If you have forms on your web site, V-A-L-I-D-A-T-E all of the data that goes into your form fields, especially if your form’s data goes into a database

Forms create a HUGE security hole to your web site. That being said, we need forms to collect data from our customers using forms on our web site. Fortunately, it is EASY to make your forms secure. First off, ask your web developer to make sure that all form fields have a maximum length set. For example, Zip Code fields need onto to allow 10 total characters. Secondly, ask your webmaster if the form fields on your web site validate all of the information that is entered. If you have a field that expects an e-mail address to be entered, the field should only allow e-mail addresses. If the field in you form only looks for dates, make sure that only dates can be entered.

Be careful how variables are passed to your web pages

A lot of web sites will pass data to a page in their web site as follows: http://www.yoursite.com/index.cfm?LocationId=1. The part of that URL, LocationId=1 is a variable, or piece of information that is used to pull up information, in this case for a specific company location in the web site’s database. If all of those LocationIds are numeric values, you will want your webmaster to make sure that only numeric values can be used by web pages on your site for the LocationId. This will protect your web site from rather serious attacks, including SQL Injection or Cross-Site Scripting attacks which can modify your site’s data or download viruses to your client’s computer.

If your site uses a database, grant only the minimum permission necessary to interact with the database

If a particular web page on your web site only reads information from the database to make it visible on the web page, ask your web master to make sure that a special “READ-Only” database user account is created to pull database from the database. This stops a hacker in their tracks from wreaking havoc on your web site’s database, because the user account that is making the data visible on your web page does not have sufficient permissions to do anything malicious to the database or its data.

If your site uses a database, grant only the minimum permission necessary to interact w/the dbase

Tweet This