If you're using only DBFree and its default configuration for running your site on internet the attack footprint is already minimized. The only port open is the one used by the web server (port 80) and there is not much else to do to make your site more secure.

The possible vulnerabilities come only from your code and the way you write it:

  1. Avoid to explicitly pass parameters on the URL (use WebForms instead).
  2. Change default action codes used in your application.
  3. Change default variable names in the code of your finalized application.
  4. Accept parameters only from known (and IP verified) pages.
  5. Use the user's browser to store some verification key and refuse pages where it misses.


Tracing is a feature of web servers that enables you to view diagnostic information about requests for web pages during development. If it remains enabled in the production environment, it poses a disclosure risk by exposing information about the internal operation of the page. Stack traces are used during the development process to provide verbose information when a server error occurs. This information can be leveraged to exploit the application as it discloses potentially sensitive information about the internal implementation of the website.

Civet has no tracing features at all, so you don't have to worry about tracing.

Custom errors

Custom error pages are used to ensure that internal error messages are not exposed to end users. Instead, a custom error message should be returned which provides a friendlier user experience and keeps potentially sensitive internal implementation information away from public view. Custom errors handling should be configured correctly. A requested URL, when not found, should not return a heading titled "Server Error in" but a more friendly page. Civet already takes care of this: it doesn't return a heading titled "Server Error in" so there's nothing more to configure with the custom errors unless you want to write a specific page to take care of this aspect.

Excessive headers

The DBFree headers have nothing to do with this: we are talking about TCP headers returned by the server, that in some case can give excessive information about what server and frameworks are used. These data are automatically returned in the response headers of the page. You can't see it unless you're using a Web Debugger. These headers can be used to help identify security flaws which may exist as a result of the choice of technology exposed in these headers. If you're using DBFree on a machine running any flavor of Windows Server this will return that your site is powered by (that is enabled by default) otherwise will return nothing so there is no need to worry about it.

HTTP cookies

Cookies not flagged as "HttpOnly" may be read by a client side script and are at risk of being interpreted by a cross site scripting (XSS) attack. Anyway most times a cookie set by the server may be legitimately read by a client script. Cookies served over HTTPS but not flagged as "secure" may be sent over an insecure connection by the browser. Often this may be a simple request for an asset such as a bitmap file but if it's on the same domain as the cookie is valid for then it will be sent in an insecure fashion. This poses a risk of interception via a 'man in the middle attack'. DBFree applications by default do not use cookies, but this is not a concern anyway because even in that case it is up to you as a programmer to avoid to put sensitive information in them.


A clickjacking attack occurs when the malicious content of another website is embedded within a frame. Obviously you should avoid to link other web sites you can't trust, but this is not a big concern anyway: DBFree from version 4 onward does not use iframes because of the responsive design adopted by its framework. Ofcourse you can always force them into your pages, but it's a little tricky. So try to avoid them.

Cross-Site Scripting (XSS)

XSS is the most prevalent web application security risk. An XSS attack occurs when an application that collects data from a user (i.e. Using a web form) is supplied with malicious content (usually containing scripts or other code intended to be run somehow). The best countermeasure is properly validating or escaping that content.

A good methode is to use 'guilty till proven innocent'-approach to formdata that is entered by the user. You should check every entryfield if it contains the string <script> for instance. And you can do a lot more. Google this subject and you will know more.

SQL Injections

SQL injection is a technique where attackers try to insert (inject) some SQL commands into an SQL statement, via web forms or URL calling. Injected SQL commands can then execute the SQL statement, read, delete or alter data stored on server. Unless you're using the ODBC connector MaxScript does not support SQL statements (mainly because it's embedded database engine is not a SQL database) so you can completely forget about SQL injections.

Check your site using an on-line service

After your site is online it is a good practice to have it checked for Security Vulnerabilities, Malware, Trojans, Viruses and online threats by using an external service. You can use on-line security scanners, they are free and simple to use: you just put the address of the site you want to scan and they do all the rest. There are other services as well: just do a google search to find out. Just keep in mind that if your home page is a standard .msp entrypoint. It won't expose itself completely to scanners, but only the portion of code generated by the action triggered by the on-line scanner. Thus if you can detect if the incoming request is from a scanner you can prepare a specific action for it. It is not fair but it can be done, if necessary. Working that way the scanner will see of your home page only what you want it to see. It is sort of cheating, but usually is called "optimization" and is done by many, usually to get better scores on benchmarks.

DBFree functions you can use

Ofcourse DBFree has functions you can use to check user input. You can check the user input ofcourse if it contains the HTML <script> tag.

DBFree function Section in Manual What is does How to use it
neutralize(cTxt) Strings neutralizing javascript and maxscript code in a text then to be shown only by using PRE tag (or saved in memo field) When a hacker has entered javascript or maxscript it gets 'neutralized' so it doesn't work anymore.
contains(cTarget, cString, nIgnorecase) Strings Return true if the first string contains the second You can check if a user has entered certain characters like <, http://, https:// or <script>. If the user has entered something like this, you can bet he/she is trying to break in somehow.