Configuring Forms Server Security Options

Security options are divided into two parts: HTTP Security Headers and Cross-Site Request Forgery Prevention.

HTTP Security Headers

There are five HTTP security headers that can be enabled and configured.

Note: See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ for more information about HTTP headers.

HTTP Strict-Transport-Security(HSTS) header
- What is it?
  - HSTS defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.
  - It significantly reduces the ability of man-in-the-middle type attacks to intercept requests and responses between servers and clients.
- What's the default value when the option is active?
  - Value: max-age=31536000; includeSubDomains; preload
    - max-age=31536000: The expire time(in seconds) that the browser should remember that a site is only to be accessed using HTTPS is 31536000(1 year).
    - includeSubDomains: This indicates the rule applies to all of the site's subdomains as well.
    - preload: Activate HSTS Preloading which makes the browser aware that the host requires the use of SSL/TLS before any connection or communication even takes place.
- How to update the option value?
  - Update the SecurityStrictTransportSecurity option from the cf_options table in the Forms database.
- What will happen if the option is enabled?
  - If the option is selected, it informs the browser to load the Forms site with https.
  - The options won't break actions when the site is loaded by http.
Note: HSTS Preloading is a mechanism whereby a list of hosts that wish to enforce the use of SSL/TLS on their site is built into a browser. This list is compiled by Google and is utilised by Chrome, Firefox and Safari. These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is already aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP. This isn't to say that the host needs to stop issuing the HSTS response header, this must be left in place for those browsers that don't use preloaded HSTS lists.
X-XSS-Protection header

What is it?
- It is a feature of Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
- Although the option may not be necessary when sites implement a strong Content-Security-Policy, the option is kept since the security option about Content-Security-Policy is disabled by default.
What's the default value when the option is enabled?
- Value: 1; mode=block
  - 1; mode=block: Activate XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
How to update the options value?
- update SecurityXXSSProtection option from the cf_options table in the Forms database.
What will happen if the option is enabled?
- If the option is selected, it should not affect any Forms functionality.

X-Content-Type-Options header
- What is it?
  - It is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed.
  - It allows users to avoid MIME type sniffing.
- What's the default value when the option is enabled?
  - Value: nosniff
    - nosniff: Block content sniffing that was happening and could transform non-executable MIME types into executable MIME types.
- How to update the options value?
  - Update SecurityXContentTypeOptions option from the cf_options table in the Forms database.
- What will happen if the option is enabled?
  - The browser will block a request if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type.
  - It should not affect any Forms functionality.
X-Frame-Options header
- What is it?
  - It can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>.
  - Sites can use this to avoid click-jacking attacks.
- What's the default value when the option is enabled?
  - Value: SAMEORIGIN
    - SAMEORIGIN: The page can only be displayed if all the ancestor frames are of the same origin as the page itself.
- How to update the options value?
  - Update SecurityXFrameOptions option from the cf_options table in the Forms database.
- What will happen if the option is enabled?
  - The Forms site will not be able to be embedded in an iframe from a different domain.
Content-Security-Policy header
- What is it?
  - It allows web site administrators to control resources the user agent is allowed to load for a given page.
  - This helps guard against cross-site scripting attacks (Cross-site_scripting).
- What's the default value when the option is enabled?
  - Value: default-src 'self' 'unsafe-inline';img-src 'self' data: blob: *.paypal.com d2egutv1ooq4p2.cloudfront.net s3.amazonaws.com;script-src 'self' 'unsafe-eval' 'unsafe-inline' *.google.com *.gstatic.com *.authorize.net *.braintreegateway.com *.braintree-api.com;frame-src 'self' *.google.com *.braintreegateway.com *.paypal.com *.paypalobjects.com blob: data:;connect-src 'self' *.authorize.net *.braintreegateway.com *.braintree-api.com *.paypal.com d2egutv1ooq4p2.cloudfront.net s3.amazonaws.com ws://{0}:8181 wss://{0}:8181 {0}:8181;object-src 'self' blob: data:;style-src-elem 'self' 'unsafe-inline' *.braintreegateway.com *.paypalobjects.com;script-src-elem 'self' 'unsafe-inline' *.authorize.net *.braintree-api.com *.braintreegateway.com *.paypalobjects.com *.paypal.com *.google.com *.gstatic.com {0}:8181
    - {0} is the fqdn name of the server hosting Forms.
    - ws://{fqdn}:8181, wss://{fqdn}:8181, {fqdn}:8181: Forms notification server requires these settings to work.
    - data:, blob:: Forms will load some images in this format.
    - self: All resources from Forms site.
    - unsafe-eval, unsafe-inline: Forms server has some inline scripts, which requires these settings.
    - d2egutv1ooq4p2.cloudfront.net, s3.amazonaws.com: The cdn server we are using, hosting BPL files.
    - *.paypal.com, *.authorize.net, *.braintreegateway.com, *.braintree-api.com, *.paypalobjects.com: Payment gateways Forms uses requires these settings to work.
    - *.google.com, *.gstatic.com: reCaptcha Forms uses requires these settings to work.
  - Related fetch directives: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy.
- How to update the options value?
  - Update the SecurityContentSecurityPolicy option from the cf_options table in the Forms database.
- What will happen if the option is enabled?
  - It will limit the data that the Forms site can load including image/js/css files, like custom images in custom themes.
  - It will limit what connections the Forms site can connect to in the browser.
  - It will limit what scripts the Forms site can execute, like external javascript urls on the form designer.
- What do you need to be aware of?
  - If you want the notification service to work with this security header, you need to check if the notification endpoint matches the value in the header value. Forms adds the value {formsHost}:8181 by default as it is the default configuration for Forms.
  - If you change the notification endpoint manually, you also need to update the value in the database by replacing all of the {formsHost}:8181 references to the desired host and port.
  - If you use external URLs such as external js/images/css, you should add the host to the script-src-elem/img-src/style-src-elem elements.

Cross-Site Request Forgery Prevention

There are two options for cross-site request forgery prevention that can be enabled and configured.

Prevent Cross-Site Request Forgery with a CSRF (anti-Forgery) token
- What is it?
  - These are also called request verification tokens and are a common way to preventing Cross-Site Request Forgery(CSRF) Attacks in ASP.NET MVC applications. These work because the malicious page cannot read the user tokens, due to the same-origin requirement policies.
  - It helps prevent CSRF attacks.
- What will happen if the option is enabled?
  - For clients or applications that use the Forms web api instead of using the Forms web site directly, they will not be able to call any non-GET Forms api without the CSRF tokens (X-XSRF-TOKEN in the request headers along with __RequestVerificationToken_xxxx in the cookie).
  - If the request does not include the token, error messages like The required anti-forgery form field "__RequestVerificationToken" is not present. will be reported in the event log.
- How to integrate with Forms api?
  - For applications that use iframe/embedded views of the Forms web site, no updates are needed, the Forms front-end code will handle all the processing.
  - For applications that directly use Forms apis to integrate with Forms, two things are necessary for invoking non-GET requests:
    - __RequestVerificationToken_xxxx cookie: appended in request; The cookie is generated on first request to Forms;
    - X-XSRF-TOKEN is appended in the request header; There will be a hidden input for every Forms page with name __RequestVerificationToken, like <input name="__RequestVerificationToken" type="hidden" value="1YjmOK2EXAuSILbzxn_FLIfFoAw6e9kN9A0oTq5PY8E5U3XAdzLg2rY08PlSsslwsjCnCTjODnUhbFt8tMwnOCGV2wrzTudCDMJ-pp7nvfY1" />, the X-XSRF-TOKEN value should be the value of __RequestVerificationToken.
Note: The cookie and token value are per session. For example, the token value will be different before and after the user logs in. We only check the tokens in non-GET requests, but for your convenience, you can append the token in all of your requests, and the Forms server will ignore it if unnecessary.
Set SameSite Cookie Attribute to Lax
- What is it?
  - It allows you to declare if your cookie should be restricted to a first-party or same-site context.
  - It is used to defend against CSRF.
- What's the default value when the option is enabled?
  - value: Lax
  - Lax: Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (when following a link, for example.)
- How to update the options value?
  - Update the SecuritySameSiteCookie option from the cf_options table in the Forms database.
- What will happen if the option is enabled?
  - Forms won't be able to authenticate within iframes that are hosted on different domains.
  - Forms won't be signed out after signing out from other applications using the same LFDSSTS when Forms and LFDSSTS are in different domains.
Notes: If you are upgrading from a previous version and have previously customized the security settings:
Changes made to cookies: For the sameSite attribute in the httpCookies section of the web.config, if you select Set SameSite Cookie Attribute to Lax in the configuration site, it will always follow that option; If Set SameSite Cookie Attribute to Lax is not checked, the sameSite value in the web.config will be followed..
Changes to http headers: If you have customized http headers in the Forms web.config customHeaders section, upgrading to a newer version will clear the customization you made in previous versions. You can enable these security options directly on the Forms Configuration site. If there are other custom http headers you want to add, you can still add them to the web.config customHeaders section.

Note: See https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/preventing-cross-site-request-forgery-csrf-attacks#anti-csrf-and-ajax and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite for additional information.

Configuring Forms Server Security Options

HTTP Security Headers

Cross-Site Request Forgery Prevention

Was this page helpful?