# App Security FAQ

## Overview

Here is a compiled list of common questions and answers around building secure apps with Airkit, ranging from best practices around TCPA, Airdata security and retention, session expiry, and more.&#x20;

## General

### Are data flows run server-side or client-side?

Data flows are run server-side, which is why they have inputs and outputs. Data that is stored at the session namespace, activity group namespace, or activity namespace is stored on the client and accessible through the browser. For more information on variables scopes, see [here](../data-and-integrations/variable-namespaces).&#x20;

### How long do sessions last?

By default, sessions have an expiration of 30 days. Session expiration time can be configured in [Settings.](../studio/builder-bar/settings) Journey's can also be extended using the [Extend Session Expiration Time](../actions/the-extend-session-expiration-time-action) action in an action chain as well.&#x20;

### How do you know if a session/journey has been completed?

Session Activity can be monitored and seen by clicking on the menu icon > **Sessions and Activity** when editing an application in the studio. Journey's can also be ended manually by using the [End Session](../actions/the-end-session-action) action in an action chain.&#x20;

### Can I build an app that requires authentication?

Yes. Airkit allows apps to be defined as Public Apps, Secure Apps, or Authentication Apps, which can be configured in [Settings](../studio/builder-bar/settings). Public apps can be accessed from anyone and are open to the public for access. Secure apps can only be accessed by being redirected through an Authentication App. The Authentication App is typically a generic app that asks for a username/password (where password is collected by a Secure Text Input Control), and when submitted, calls the [Set Authentication Action](../actions/the-set-authentication-action). If the username/password matches the authentication parameters, then the Set Authentication Action redirects the user to the Secure App Journey. The Secure App also has a cookie that can be set, which will redirect the user back to the Authentication App when it is expired.&#x20;

#### What if I want to require authentication from a third party rather than a password?

Airkit allows app users to be authenticated via [SAML](../authentication/saml-authentication) as well as multiple OAuth 2.0 venders, including [Google](../authentication/setting-up-google-oauth), [Okta](../authentication/oauth-20-okta), and [Auth0](../authentication/oauth-20-auth0). All available OAuth app authentication options adhere to the Open ID Connect spec. When verification succeeds and the user provides consent, the user information can be surfaced via the **On Authentication Success** Event, and he JWT from the vendor remains in the browser as a cookie.

### Are assets uploaded to the [Media Library](../studio/builder-bar/media-library) scanned for any malware or viruses?

Yes, assets uploaded to the Media library are scanned for trojans, malware, viruses and other threats. If a malicious file is detected, the asset will be rejected.&#x20;

### Are my API tokens in console secure?

Yes, API tokens and credentials that are uploaded via integrations are stored in an encrypted vault.

### How does Airkit handle App isolation?

Customer can bring as many domains ([custom domains](../administration/custom-domains)) as they want. App isolation is essentially enforced at a domain level, so you can set up apps on their own subdomains if needed. The app developer has full control over where APIs and/or Apps live and which domain they're on.

## Attack Prevention

### How does Airkit prevent clickjacking?

The Airkit platform cannot be accessed within an iframe, prevented by setting `content-security-policy: frame-ancestors 'none'`. This prevents clickjacking while working within the Console or Studio. As far as authentication, cookies are secure-only and have a `Same-Site: Lax` security policy.

To protect against clickjacking when inserting your apps into an iframe, you must explicitly allow specific target domains if you want to embed your Airkit app. The default `content-security-policy` only allows apps to be embedded in the Studio/Preview and (if applicable) Airkit portals. The “Embedded External Content” control sets the iframe `sandbox` property to `allow-scripts allow-forms` to provide a balance of functionality and security. Content embedded within an Airkit app may not modify the parent frame. Any application authentication cookies are secure-only and have a `Same-Site: Lax` security policy.

### How does Airkit protect against CSRF?

Airkit limits the risks of CSRF attacks in a variety of ways. Authentication cookies require HTTPS, are inaccessible from Javascript (http-only), and have a `same-site: lax` policy. All API requests contain an `XSRF-Token` to prevent to prevent cross-domain form submission. `GET` requests never modify data.

## Embeds and Iframes

### How is the CORS access policy configured?

When embedding your Airkit apps into your existing digital portfolio, CORS must be done on an application-by-application basis. Target hostnames are defined under **Studio > Settings > Target Names**. When using [Airkit Embeds](../embeds/airkit-embeds), these target hostnames will always be applied. When using [SDKs](../embeds/sdks), these target hostnames will be applied only if **Enable CORS** (found under **Studio > Triggers > SDK > Authentication**) is checked, which is done but default upon the creation of an SDK Trigger. For more on how this is implemented, see the [SDK Quickstart](../embeds/sdks/sdk-quickstart).

## Data

### What realms are Airkit Apps and data stored?

When an [Airkit Organization](../administration/airkit-organizations) is provisioned, the organization and all assets pertaining to that organization are stored in a [realm](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) that is selected at purchasing. These realms include United States (us-west-2), Australia (ap-southeast-2), and the EU (eu-central-1). If you are not sure what realm an Airkit Organization is provisioned in, please reach out to your sales representative or reach out to support@airkit.com.

### Where is data in Airdata stored, and is it secure?

Airdata is encrypted at rest, encrypted in transit between systems and encrypted on the server itself. Our online infrastructure is built on Amazon Web Services, and Airkit maintains a SOC2, PCI, HIPAA and other controls that cover the service's security, confidentiality, availability, and integrity. For more information, see [https://www.airkit.com/security/](https://www.airkit.com/security/).

### How long is data retained?

Data stored in Airdata is retained unless it is manually deleted. Session data, on the other hand, is stored for the length of the session duration. Session duration is configurable by the user in configuration builder and can also be extended by using the [The Extend Session Expiration Time Action](../actions/the-extend-session-expiration-time-action).&#x20;

### I am an Airkit customer that is in Europe and is subject to GDPR. How do I ensure my data stays within the EU?

When an Airkit organization is provisioned, you have the ability to select a realm for where your data resides. If you select an EU realm, your data will stay within the EU-Central-1 AWS region. Please note that as a developer you have the ability to call APIs and copy data globally, the realm constraint ensures that Airkit will not move your data or processing outside of that region.

### I am an Airkit customer that is subject to HIPAA. How do I ensure my application remains HIPAA compliant.

When an Airkit organization is provisioned, you have the ability to select a realm for where your data resides. If you select a US realm, your data will stay within the us-west-2 AWS region, and ensures that Airkit will not move your data or processing outside of the US realm. As a developer, you also have other tools available to help you build applications to help meet HIPAA requirements. Airkit supports [encryption](encrypting-data), using Airkit's default keys or you can bring your own key, along with data tagging in AirData. There is also the [secure text input control](../web-controls/secure-text-input-web-control) so that inputs can only be accessed server-side and not saved on the browser as well as the [Secure Touchtone Capture Control](../voice-and-chat-controls/secure-touchtone-capture-control).

### Where is the data from inputs or variables stored?

Data that is input on the client is saved on the browser. If using the [secure text input control](../web-controls/secure-text-input-web-control), the values input into that control are not surfaced on the browser. Using the secure text input control generates a `secureValueKey` that can be accessed through a data flow using the [The Secure Value Retrieval Data Operation](../data-operations/the-secure-value-retrieval-data-operation).

### How are assets retained on Airkit servers?

Assets in Airkit are uploaded to Amazon S3, in a separate bucket per org, per application. Assets can either created as a global asset or a private asset. Global assets are available on the CDN with a static link. Private assets have a generated link and has an expiration time which is configurable. See [The Asset Data Type](../variable-data-types/the-asset-data-type) for more information.

### How do I handle secure data when building in Airkit?

Secure data can be handled by using the [Secure Text Input Web Control](../web-controls/secure-text-input-web-control), [Secure Touchtone Capture Control](../voice-and-chat-controls/secure-touchtone-capture-control), or by using PCI compliant controls such as the [Credit Card Control](../web-controls/credit-card-web-control) or the [Payment Request Button Control](../web-controls/payment-request-button-web-control).&#x20;

### How are emails handled in Airkit?

When using the [The Send Email Data Operation](../data-operations/the-send-email-data-operation), emails get routed through Amazon SES and do not sit on Airkit servers. Mailboxes are also not hosted by Airkit and receiving emails are the responsibility of the mailbox owner.

## TCPA

### What are some best practices for building an application that is TCPA compliant?

The best way to ensure TCPA compliance when building out an application, is to first be able to extract a user's state and timezone locale. The best way to do this, is to ask for a user's zipcode, and use a zipcode lookup API to extract state and timezone. Using this information, chat/voice bots can be triggered on [timers](../building-apps/timers-and-reminders/setting-timers) that can be restricted to only run based on a TCPA calendar. The calendar restriction must be to either **Do not schedule and cancel** or **Schedule in next available time slot**. For more information on TCPA, see [How To enforce TCPA](tcpa).

## PCI Compliance

### What are best practices when building a PCI compliant application?

When building a PCI compliant app, ensure that no sensitive data is saved on the client. Data that is deemed sensitive should use the [Secure Text Input Web Control](../web-controls/secure-text-input-web-control), and pass that data to be retrieved server side, through a data flow. Also, data that is passed to the data flow should not be returned as an output, or else the application is no longer PCI compliant. Also, when capturing credit card information, Airkit has PCI specific controls that are PCI compliant out of the box, such as [Credit Card Web Control](../web-controls/credit-card-web-control) and the [Payment Request Button Web Control](../web-controls/payment-request-button-web-control).
