# Security Hardening Guide - Development This page outlines the security aspects to be considered when developing with Caplin products or carrying out security testing assessments when testing against your Caplin client and server stacks. The provided information is intended for use by developers who wish to implement a secure environment as they develop with Caplin product(s). See further down for the recommended security practices that are currently applicable. **📌 NOTE**\ For the recommended security practices when **deploying** a Caplin product, see [Security Hardening Guide - Deploying](security-hardening-guide-deploying.md). ## Server-side Integration Recommended security practices when integrating with Caplin server-side components. ### Validate all data sent sent from clients **📌 NOTE**\ [Caplin Platform](index.md) server-side components do not, out-the-box, perform validation on the authenticity of the trade data sent from the client. This responsibility is to be handled by your existing trading systems. In the case of authenticating trade prices for deal execution, there are several ways to handle this from past observations by Caplin: * To send any price updates to the client with a **priceID** field: When a client receives a price update from the server prior to execution, a trade execution message is sent to the server along with the corresponding **priceID** field. The server can then use the **priceID** to cross-reference against what it knows to be genuine prices that were previously sent out by the bank to the client (during the price updates). In addition to this, as further validation, the server can also cross-reference the 'age' (timestamp) of the **priceID**. * For the trading system to set thresholds of tolerance for the deal price validation sent through from the client and accept / reject depending on the how it favours the bank. This need not be implemented by the existing trading system, a Trading DataSource Adapter can be well-placed to implement this business logic. As a client is operating the web trading application from within a web browser, you must be aware that anyone can potentially use the debug console to execute JavaScript whilst the application is running. We recommend you ensure that these test cases are covered in your UAT environments prior to deployment in a production environment. ### Escape all data from untrusted sources Any user submitted input at the client side that is to be to sent to the server and be persisted somewhere will need to be encoded For example, data contained in a trade blotter would normally come from the back-end systems; however, if any blotter data is from the client then it should be output encoded in order to prevent possible **XSS attacks**. ### Reinforce permissions for trading-on-behalf-of (TOBO) others Trading on Behalf of (TOBO) features that are available across Caplin products, such as the [FX Sales Motif](../../fx-sales/index.md), should be reinforced with explicit permissioning config. With TOBO, a sales user can trade FX on behalf of others, such as clients. In the FX Sales Motif, specific [trade messages](../../fx-sales/st-trade-messages-in-the-motif.md) send a `TOBOUser` field to [Liberator](../liberator/index.md) whenever a sales user submits or executes a trade (see Submit and Execute messages in the [RFS trade model](../../fx-integration-api/fxapi-trade-model-rfs.md)). This **TOBOUser** field is used for specifying the client that the sales user is permissioned to trade on behalf of. If the sales user is not permissioned to trade on behalf of the client specified, then the trade message should be rejected by Liberator. If there are no checks to validate sales user/client permissioning, then it is possible for the trading system to proceed booking the trade as normal as it would have expected the value for TOBOUser to have been validated prior to booking. Reinforcing the permissions behind TOBO related trade messages is something that can be done either programmatically (generated) or configured via XML configuration. You can find useful information on permissioning concepts and configuration options in the following documentation: * [Permissioning Concepts](permissioning-concepts.md) * [Permissioning for TOBO](permissioning-for-tobo.md) ## KeyMaster Servlet Authentication [KeyMaster](../keymaster/index.md) is a servlet that facilitates the process of logging into [Liberator](../liberator/index.md) via [StreamLink](../streamlink/index.md) as you access financial data through the Caplin [FX Professional](../../fx-professional/index.md) web app. KeyMaster integrates with your existing single sign-on (SSO) system to maintain secure access to financial data contained within Liberator. If you have configured a web application to use KeyMaster , please see the following security recommendations. ### Base your implementation on JndiKeyMasterServlet The KeyMaster Java SDK incudes several implementation examples to get you started. When it comes to deploying FX Professional into a production environment, it is strongly recommended that you base your own implementation on the **JndiKeyMasterSerlvet** example. See the following pages for more information on installing and configuring KeyMaster: * [Installing KeyMaster](../keymaster/keymaster-installing-keymaster.md) * [Server configuration](../keymaster/keymaster-keymaster-servlet-config.md) * [Setting up Liberator to work with KeyMaster](../keymaster/keymaster-setting-up-liberator-to-work-with-keymaster.md) Detailed information on hardening KeyMaster security for production environments: * [Hardening KeyMaster security](../keymaster/keymaster-making-keymaster-secure.md) **⚠️ WARNING**\ Do not use the **UnsecureUrlParameterCredentialsProvider** class in the provided example servlets outside of development or in a production environment for authentication testing. ### Encode additional data sent in KeyMaster authentication tokens The [KeyMaster process of authentication](../keymaster/keymaster-keymaster-architecture.md) when logging into Liberator allows for extra data to be appended to the creation of a valid [authentication token](../keymaster/keymaster-keymaster-concepts.md) that will be verified by Liberator. If you are creating a KeyMaster implementation that makes use of these additional parameters as part of a single sign-on, it is recommended that you encrypt any extra data to prevent this data being sent in plain-text. If you have any technical queries regarding this - please contact [Caplin Support](https://account.caplin.com/account). **❗ IMPORTANT**\ Do not encrypt KeyMaster token values that are read by Liberator. Examples include token values in Permissioning Auth Module (PAM) [field-match criteria](complex-permissioning-rules.md#field-match-criteria) and token values in [object-map](../liberator/liberator-object-configuration-part-2.md#object-map) configuration items. --- **See also:** * [Security Hardening Guide - Deploying](security-hardening-guide-deploying.md)