Integration Security

Securing your integrations on Frends Platform.

It is important to consider security when designing integrations. Frends can transfer confidential data between systems, and all the necessary efforts should be taken to prevent the data from being accidentally deleted or modified, or deliberately misused or stolen. The following sections describe the best practices to use when designing and developing secure integrations.

Access to Frends Tenant

Due to the nature of the integration platform, Frends users may be able to gain access to external systems and sensitive data regarding integration processes. This is why the user list and the users' roles must be kept up to date and no user should have a role they do not need. For auditing purposes, it is important to have an up-to-date list of authorized users.

It is best to attach the authentication for Frends Control Panel to the customer's own Azure AD in order to have full control of who can log in to Frends Control Panel. Also this way it is possible to enable multifactor authentication.

Credentials and secret values

Usernames and passwords are recommended to be stored in Environment Variables. Passwords should always use the type secret in the variables. Every secret and password value should consist of at least twelve characters with at least one upper case letter, one lower case letter, one number, and one special character. There should be a different password for every Environment and every external system.

When creating a new Process, the developer creates the Environment Variables for the credentials, and Company’s integration owner or another person that has access to the credentials fills them in in Frends. Passwords or any other secret values should never be distributed with the related username or ID. Any secret value is not allowed to be sent in clear text or an unencrypted email.

Security considerations within Processes

If production data is to be used for testing it should be masked to protect personal identifiable information (PII) and commercially sensitive data.

Only encrypted transfer protocols such as HTTPS and SFTP should be used.

API Development

In API development it is recommended to use OAuth for authentication and API key for authorization. Other security considerations for APIs are:

• IP address filtering

• Rules for allowing and denying CRUD operations

• Limiting transaction amounts

• Blocking faulty headers

• Input parameter validation

Using SQL

When using SQL in Processes, it is recommended to use parametrization and other SQL-related security practices to avoid SQL injections. SQL Tasks in Frends include built-in fields for entering parameter values to help with this.

Using LDAP

When using LDAP tasks in Processes with user-provided input, it is recommended to sanitize input values to avoid LDAP injection attacks. Special characters such as *, (, ), \, and / should be escaped before using them in LDAP filter fields.

Processing XML

When processing XML from untrusted sources, it is recommended to disable external entity processing to avoid XXE (XML External Entity) attacks. Tasks such as Frends.XSLT.Transform include options to disable external entities. XML should be validated against known schemas where possible.

Executing Commands

When using PowerShell or Python execution tasks with user input, values should never be concatenated directly into command strings. Use ProcessStartInfo.ArgumentList with validated input parameters and avoid UseShellExecute = true when possible to prevent command injection.

File Path Handling

When handling file paths from user input, it is recommended to validate paths against allowed directories and sanitize file names to remove path traversal characters such as .., /, and \. File paths should be verified to remain within intended directories using absolute path validation.

HTTP Headers

When constructing HTTP headers with user-provided values, it is recommended to remove newline characters (\r, \n) to prevent header injection attacks. URLs from user input should be validated to ensure they use allowed schemes and do not target internal IP ranges.

Logging User Input

When logging data that includes user input, sensitive information should be masked and input should be sanitized to prevent log injection. Newline characters should be removed and log entries should be limited in length. Passwords, API keys, and authentication tokens should never be logged.

File Uploads

When processing uploaded files, it is recommended to validate file types by content (magic bytes) rather than file extension alone. File size limits should be implemented and file structure should be validated before processing.

URL Parameters

When using user-controlled URLs in HTTP tasks, it is recommended to validate URL schemes and block access to internal IP ranges to prevent SSRF (Server-Side Request Forgery) attacks. Only HTTP and HTTPS schemes should be allowed unless specifically required.

Logging and Archiving

Frends enables easy and comprehensive logging features for the Processes for easy development and debugging of Processes, but for production use logging and archiving the handled data is recommended to be disabled.

The log level for the Production Environment should be set to "Only errors". APIs that handle sensitive data should be designed and implemented so that it is possible to log only the error and no other content of the message when an error occurs. Logging other data than errors should be carefully considered.

GDPR

General Data Protection Regulation (GDPR) requires companies to protect the personally identifiable information (PII) of their employees, customers, and third-party vendors. For example, the following can be considered as PII:

• Full name

• Home address/mailing address

• Email address

• Credit card numbers

• Date of birth

• Phone numbers

• Login details

• Precise locations

• Account numbers

• Security codes

• IP addresses

• User IDs

• E-commerce order IDs

When logging or archiving PII, the following should be considered and documented:

• What data is collected and why

• Where the data is stored

• Who has access to the data

• What does the legislation say about storing the data

• How long it is meaningful to store the data

• When deleting the data, possible error situations should be taken into account

• Is it possible to delete data according to certain criteria, e.g. name or email address?

The integration owner should maintain a list of users that have access to the integration logs and archives.

High Availability

Having two or more Agents allows them to share the load, and ensures that services are available even if some event, like operating system updates or a huge peak in load, renders one Frends Agent unavailable for a moment.

Usually, if Frends Agents are used to delivering integrations to some critical or "real-time", e.g. mobile, application it is advisable to use multiple Agents in production.