Security module


About

The Security module lets administrators configure security settings for Content Hubs and legacy Video Portal sites. These settings include enforcing HTTPS connections, restricting playback to specific IP addresses, and configuring HTTP security headers.

HTTP security headers help control how browsers load resources, share information, and interact with content from other origins.

Configure the module

1.Go to your Configuration Management console, locate the Security module in the left panel, then select it. You can also navigate directly to:https://{your_KMS_URL}/admin/config/tab/security

The Security page displays.

2. Configure the following settings:

allowLoadInIframe - Allows the site to be loaded in an iframe. The default is No to help prevent cross-frame scripting (XFS).

enabledHsts - Returns the HTTP Strict Transport Security (HSTS) header. HSTS instructs browsers to access the application domain using HTTPS.

This header is returned automatically when sslSettings is set to All Site in the Auth module. When HSTS is applied, the browser automatically uses HTTPS for subsequent attempts to access the domain.

securePlaybackWithIprestrict - Restricts each Kaltura Session (KS) to the IP address from which playback was requested, providing additional protection against unauthorized sharing. For more information, see How to create a Kaltura Session.

The user's IP address is included in the KS. If someone copies and shares an embed code containing that KS, playback is denied when the recipient accesses the Kaltura API from a different IP address.

Content Security Policy settings

A Content Security Policy (CSP) tells browsers which sources the site is allowed to load resources from, such as scripts, styles, images, fonts, media, and embedded content. This helps protect the site against cross-site scripting and other code-injection attacks.

cspHeader - Adds an enforced Content-Security-Policy HTTP header to the site pages. The policy controls which resources the browser is allowed to load. If adminCspHeader is empty, this policy also applies to the Configuration Management console.

If cspHeader is empty, administrators see a security alert once per login session in the Configuration Management console. Administrators can dismiss the alert for the current session, but it appears again during subsequent sessions until cspHeader is populated.

cspHeaderReportOnlyHeader - Adds a Content-Security-Policy-Report-Only HTTP header to the site pages. The policy isn't enforced, so resources aren't blocked, but violations are logged in the browser's developer tools. Use this field to test a proposed policy before enforcing it.

adminCspHeader - Adds an enforced Content-Security-Policy HTTP header specifically to the Configuration Management console. When this field is populated, it overrides cspHeader for the console. If it is empty, the console uses the policy configured in cspHeader.

adminCspHeaderReportOnlyHeader - Adds a Content-Security-Policy-Report-Only HTTP header specifically to the Configuration Management console. The policy isn't enforced, but violations are logged in the browser's developer tools.

Nonce tokens

You can use the following tokens in any of the CSP fields:

  • Use the 'nonce-{{scriptNonce}}' token to generate a random nonce string that is included in script tags.
  • Use the 'nonce-{{styleNonce}}' token to generate a random nonce string that is included in style tags.

Enter only the policy directives in the CSP fields. Don't include the Content-Security-Policy: or Content-Security-Policy-Report-Only: header name.

CSP requirements depend on the resources, integrations, and customizations used by your organization. Test the site thoroughly after adding or changing a policy. An incomplete or overly restrictive policy may prevent legitimate resources or functionality from loading.

For instructions on creating, testing, and applying a policy, see Configure a Content Security Policy (CSP) header.

Additional HTTP security headers

permissionsPolicyHeader - Adds the Permissions-Policy HTTP header, which specifies which browser features the site is permitted to use.

referrerPolicyHeader - Adds the Referrer-Policy HTTP header, which controls how much referrer information is included with requests.

Choose from the following options:

  • no-referrer
  • no-referrer-when-downgrade
  • origin
  • origin-when-cross-origin
  • same-origin
  • strict-origin
  • strict-origin-when-cross-origin
  • unsafe-url

crossOriginEmbedderPolicyHeader - Adds the Cross-Origin-Embedder-Policy HTTP header, which controls whether the page can load cross-origin resources.

Choose from the following options:

  • none
  • unsafe-none
  • require-corp
  • credentialless

crossOriginOpenerPolicyHeader - Adds the Cross-Origin-Opener-Policy HTTP header, which controls whether a top-level document shares a browsing context group with cross-origin documents.

Choose from the following options:

  • none
  • unsafe-none
  • same-origin-allow-popups
  • same-origin

crossOriginResourcePolicyHeader - Adds the Cross-Origin-Resource-Policy HTTP header, which instructs browsers to block certain no-cors cross-origin or cross-site requests.

Choose from the following options:

  • none
  • same-site
  • cross-origin
  • same-origin

Additional security settings

useTrueClientIp - Determines the user's IP address using a trusted HTTP header configured by Kaltura DevOps or through your CDN.

  • Enabled - Uses the configured trusted header instead of potentially spoofed X-Forwarded-For values.
  • Disabled - Uses standard IP detection, such as REMOTE_ADDR.

Enable this setting only when the trusted header has been properly configured.

allowedExternalReferrer - Controls which external domains can be used as redirect destinations in the referrer parameter. This helps protect the site against open-redirect vulnerabilities.

  • All Domains - Allows redirects to any external domain.
  • Specific Domains Only - Allows redirects only to the site domain and the trusted external domains configured in allowedRefDomains.

When you select Specific Domains Only, the allowedRefDomains field displays. The site domain is always allowed and doesn't need to be added.

To add an allowed domain:

  1. Click Add "allowedRefDomains".
  2. In the domain field, enter the trusted domain, for example, lms.university.edu.
  3. Repeat these steps for each additional domain you want to allow.

hideVersionEndpoint - Controls whether the /version endpoint is publicly accessible.

  • Disabled - Allows access to the endpoint.
  • Enabled - Returns a 403 response and prevents unauthenticated users from viewing the application version and build number.

enableIdleTimeout - Automatically signs users out after a specified period of inactivity. Before they are signed out, users receive a warning and can choose to remain signed in.

  • Off - Disables automatic sign-out due to inactivity.
  • On - Enables automatic sign-out according to the values configured in idleTimeoutDuration and warningPeriod.

idleTimeoutDuration - Sets the number of minutes a user can remain inactive before being signed out automatically. Enter a value from 5 to 1440 minutes (24 hours). This setting applies only when enableIdleTimeout is enabled.

warningPeriod - Sets how many minutes before the idle timeout users are warned that they will be signed out. The value must be less than idleTimeoutDuration. This setting applies only when enableIdleTimeout is enabled.

  • 3. When you have finished configuring the module, click Save.
  • Was this article helpful?
    Thank you for your feedback!
    User Icon

    Thank you! Your comment has been submitted.

    In this article
    Related articles