Securing applications

This page describes how to design data management applications to ensure data security. It details the capabilities to track and prevent data breaches in applications.

HTTP security

There are several security aspects to consider with applications:

  • Securing communication: the browser and the xDM server exchange information, including the data displayed in the application. This information is transferred over the HTTP protocol, which is not encrypted by default. We strongly recommend configuring the application server hosting xDM to serve all its resources over the HTTP(S) protocol.

  • Cross-origin resource sharing (CORS): CORS is a mechanism that allows other applications access resources from xDM applications. By default, xDM (both the applications and the REST APIs) is configured to deny cross-origin requests. Administrators can use the corsAllowOrigins system property to declare trusted servers with which CORS is enabled. For example, use -DcorsAllowOrigins=http://example.acme.com to allow this server to access resources in xDM applications.

  • Embedding: embedding involves rendering applications within another page (e.g., using an <iframe> element), which can pose clickjacking risks. For instances running on Apache Tomcat, administrators can configure the allowed contexts in which xDM can be embedded by setting the HttpHeaderSecurityFilter properties in the web.xml file (specifically, the antiClickJackingEnabled, antiClickJackingOption, and antiClickJackingUri properties). By default, the Preconfigured and Docker images only support embedding in applications served from the same server (with antiClickJackingOption set to SAMEORIGIN).

  • Measures against cross-site scripting (XSS), content sniffing, clickjacking: these measures should be implemented at the application server level. For example, you can configure Tomcat’s HTTP header security filter to address these issues. Similarly, implementing IP address filtering and restrictions is a good practice when the application is accessible over the Internet.

  • Cookies: the application server may use cookies that contain sensitive data, such as session identifiers. These cookies can be stolen:

    • Via XSS attacks if accessible to JavaScript code. To prevent this, the HttpOnly attribute should be set in the Set-Cookie HTTP response header. For example, use the useHttpOnly property in the Context configuration in Apache Tomcat.

    • Via man-in-the-middle attacks. To prevent this, the Secure flag should be set in the Set-Cookie HTTP response header, ensuring cookies are only sent over encrypted HTTP requests. For example, use the secure property in Tomcat’s HTTP Connector configuration. Note that this requires setting up secured communications with HTTP(S).

Secured application design

Data management applications run within a web browser and display pages generated from model elements (such as forms, collections, etc.) combined with data from records stored in the hub.

In Semarchy xDM applications, three types of form or collection field types allow script execution: Markdown, Hyperlink, and Object. These fields allow designers to run scripts within collections and forms to enhance the user experience. Model designers are always regarded as trusted sources in terms of application security and are authorized to insert scripts within forms and collections.

These fields can also display data entered or imported by end-users or integrated from external sources, combined with designer scripts. For example, to display an access map using Google Maps, designers may use a script that incorporates an address entered by a user. There is a risk that an attacker could inject a script or reference external scripts within the data, potentially executing silent operations using the connected user’s credentials.

For example, if a Markdown field is used to display rich text content entered by users, there is nothing to prevent a user from including HTML content, such as <script> tags, with code that uses the internal communication API between the web browser and the xDM server to insert, update, or delete data records. This script would execute within the web browser with the credentials of the connected user.

To prevent such attacks, designers should use these fields with extreme caution, preferably rendering only information from trusted sources. If possible, data should be sanitized using SemQL enrichers and validations. For example, SemQL validation can be used to reject values that contain <script> tags.