Our CMS comes with a layered security policy to ensure all data passed to and from any dynamic storage medium is sanitised and validated.

One of the layers in the CMS first checks for common SQL Server attacks, if found, it refuses to deliver the page. This is done "at source" level of the HTTP header request and effectively denies any further access to any other layer of the page.

In addition, we have also employed a "hash key" check on any parameters passed through the query string. Such obvious attack layer is typically ignored by other CMS's, but is vital to ensuring any data passed by a CMS created page or value or by any custom values passed through non CMS data is sanitised before being used. So, if anyone tries to fiddle with the query string values / data, it is detected and as with the SQL Injection attack layer, the request is prevented from processing any further.

Since our CMS is also our own product, built in-house by our experienced developers, another attack vector we're not prone to is the openness some GPL products offer. Though we are not against GPL, we're a big fan of it, products based on them are widely used and hence widely popular for hackers to break into knowing once broken, they have large market to exploit. With our CMS development under lock and key with no internals exposed, it adds to our security policy and yours.

Though nothing is fully secure, after all humans are inherently error prone, the security practices we put in place should prevent the most common of attack vectors.