It's important to pay attention to security in just about everything we do as developers. It's impossible to check everything from within the middle layer without making sacrifices to performance and features. xxm has a few design choices and features added to help build secure applications, but in the end it still takes a bit of work and attention from your end. Here are a few known issues, tips and tricks, but new soft spots may appear, both in xxm and in other applications out there on the web, so keep an eye and ear open.
things xxm does
XSS (cross-site-scripting)
Most cross-site-scripting can be prevented by choosing correctly between Context.Send(x) (or [[=x]]) and Context.SendHTML(x) (or [[#x]]). In fact, it's strongly advised to use normal Send ([[=x]]) in most cases, and only use SendHTML ([[#x]]) in those cases where it's neccessary, and even then never on strings retrieved from database or a Context.Parameter[] unless it's properly stripped from any possibly malicous code (HTML and JavaScript).
You might worry about performance when HTMLEncode gets called on almost everything, but xxm's several overload functions don't call HTMLEncode on variant types where it doesn't matter, such as numeric values.
SQL injection
xxmData.pas uses ADO command parameters to run queries. This encapsulates parameter values safely into the SQL to perform.
See xxm_demo.zip demo "03 Data" for an example.
scripted posting
The default xxmSession.pas denies page access if a new session is created on a POST request.
things xxm doesn't do
when to pass values over form fields, url parameters, session data, cookies
The default xxmSession.pas uses Context.SessionID which creates an XxmSession cookie. This value is used to retrieve a session data object into a Session threadvar from the session store. Add identifying information to the session object (such as a user ID as used in the database) but only allow changes under proper authentication (such as login and password).
//TODO: alternative proto templates could add a Session local variable to the default TxxmFragment class inherited from by each fragment/page.
Never pass values that are not supposed to change over URL parameters or form fields. By passing them to the browser and picking up the values when they return, you enable the user to modify the values. One exception may be acceptable to this rule: identifying values (see also re-validate posted forms).
A method to protect data stored in (persistent) cookies (that is a cookie with an expiry date in the future) is encryption, or using an id refering to data in the database.
check a Context.Parameter is a POST parameter from a form field (not a GET parameter from the query string in the URL)
Context.Parameter provides access to all parameters of the page request, all parameters expose the IXxmParameter interface, but a POST parameter does expose the IXxmPostParameter interface. Check this by using as or QueryInterface
If you perform client-side validation, or have sections of the form that are hidden depending on authentication or priveleges, re-check values and permissions when processing posted values.
prevent you from making mistakes
I've elected to not include this in the design goals of xxm. You're supposed to know what your doing, and be responsible about working on an online platform that will respond to requests of people. Even if they have malicious intent or are not even people but automated bots that search for vulnerabilities of your web-solution.
more reading