Xojo Documentation Xojo Documentation

Because web apps are accessible to any number of online users, the security of web apps is paramount. Xojo web apps are serious about security.

Most traditional web development languages are interpreted, meaning your web app is a set of files on a server. If someone gains access to that server, they gain access to your source code. Xojo web apps are compiled to binary code so your source code is not stored on the server.

In order for someone to alter your app they would have to be very familiar with x86 assembly code and be willing to spend a lot of time tracing through that code. This is, at the least, an order of magnitude far more difficult than hacking HTML, JavaScript, CSS, AJAX, and PHP or Java source code.

The Open Web Application Security Project (OWASP) provides information on web app security and posted a list of the top 10 web app security issues. While a few of these issues require the developer to be more diligent, most cannot be used to hack into a web app created with Xojo.

Hack	Xojo Protection
SQL Injection Attacks	Xojo provides developers with prepared statement support for database access. This takes the values to be used in a query and sends them separately to the database server so that it can determine if the values are valid or contain SQL.
Cross-Site Scripting	Xojo web apps can’t be used for this purpose because all data sent to the browser is automatically escaped. As a result, the user cannot inject HTML into a page. Also, because the developer doesn’t work in HTML or JavaScript, there’s no way for the developer to accidentally create this security breach.
Application Authentication	Xojo does not have authentication routines to compromise and session tokens are automatically protected from theft.
Insecure Direct Object References	Xojo does not allow direct object references in this manner so it would be impossible for such a security hole to be created.
Cross-Site Request Forgery	When the user logs into a web site (such as a banking site) and then leaves by navigating to a page of another site without first logging out, the original site will still see the user is logged in until their session times out. The developer can mitigate this by reducing the timeout from the 60 second default.
Security Misconfiguration	This involves the developer making sure they have good passwords for their server, not exposing data that does not need to be exposed, etc. This particular security concern is completely within the control of the developer and is outside the scope of what any development tool can guard against.
Insecure Cryptographic Storage	Be sure to use appropriate function in the Crypto library to properly secure your data.
Failure to Restrict URL Access	Because Xojo web apps create the HTML page on the fly, there’s no way for a hacker to access any page except the one that is currently in their browser. However, if the developer chooses to support bookmarking, they would need to make sure they authenticate the user before taking the user to the requested page.
Insufficient Transport Layer Protection	Web Servers provide SSL support which is the appropriate place to handle this issue.
Unvalidated Redirects and Forwards	There is nothing any development tool can do to prevent this. It’s up to the developer to make sure their app doesn't depend on untrusted data when redirecting or forwarding the user to another site. For example, the developer should always use the EncodeURLComponent function to encode any values used in a URL which come from a user or database.

Go here to read a full description of each of these types of hacks.