Zum Hauptinhalt springen
Deutsch
|
English

ALLOWEDREFERERS - Detailed description

FM-Portal

IC2862
FM-Portal

Overview

Parameter:ALLOWEDREFERERS
Category: Custom Default
value: "" (empty)
Product: eTASK.Other (Custom)

What does this parameter do?

This parameter defines a list of trusted domains from which the portal accepts requests when CSRF protection (ANTICROSSSITEREQUESTFORGERY) is enabled. If users are logged in via external authentication services such as Microsoft Azure Active Directory, these services must be included in this whitelist. Otherwise, the portal would block the return from the login service as a potential attack.

What is this parameter used for?

  • Defining trusted external domains for CSRF protection

  • Allowing redirects from external authentication services (e.g., Azure AD, OAuth providers)

  • Whitelisting of partner portals or integrated services

  • Prevention of false blocking of legitimate requests when CSRF protection is enabled

  • Configuring Single Sign-On (SSO) integrations with external identity providers

Technical Details (for Administrators)

Format: Comma-separated or semicolon-separated list of URLs
Default value: "" (empty)

Valid values:

  • "" = Empty (no external referrers allowed)

  • https://login.microsoftonline.com = Single domain (Microsoft Azure AD)

  • https://login.microsoftonline.com,https://partner.example.com = Multiple domains (comma-separated)

  • https://login.microsoftonline.com;https://partner.example.com = Multiple domains (separated by semicolons)

Important notes:

  • Domains must be specified in full with the protocol (e.g., https://login.microsoftonline.com)

  • Multiple domains can be separated by commas or semicolons

  • Spaces before and after the entries are automatically removed

  • The parameter is only evaluated if ANTICROSSSITEREQUESTFORGERY is set to 1 (enabled)

  • The system compares only the domain (authority), not the full path

  • Uppercase and lowercase letters are ignored (case-insensitive)

Interaction with other parameters:

This parameter is closely linked to ANTICROSSSITEREQUESTFORGERY. Without CSRF protection enabled, this parameter has no effect. When CSRF protection is enabled, it is mandatory if external authentication services are used.

When should you change this value?

Configure the value (enter domains) if:

  • You use Azure Active Directory or other external authentication services

  • ANTICROSSSITEREQUESTFORGERY is enabled and external logins do not work

  • You use SSO integrations with partner systems

  • The portal is integrated with external OAuth or SAML providers

  • Users are redirected to error pages after logging in from external services

Leave the value blank if:

  • ANTICROSSSITEREQUESTFORGERY is disabled (value 0)

  • Only local authentication (username/password) is used without external services

  • There are no integrations with external systems

  • The portal is operated exclusively internally without external redirects

Important Notes

  1. Enter only
    trusted domains Enter only domains that you fully trust. Any entered domain can send requests to your portal that are accepted by CSRF protection.

  2. Full URLs with protocol Always
    use full URLs including the protocol (https:// or http://). Incomplete entries such as "login.microsoftonline.com" will not be recognized.

  3. Test after changes After
    every change, test the entire login process using all authentication methods to ensure that no legitimate requests are blocked.

  4. Regular review
    Regularly check whether all registered domains are still needed. Remove outdated entries to enhance security.

Security

Does changing this parameter affect security?

Yes, this parameter has significant security implications, as it defines which external domains are granted access to your portal.

Positive aspects:

  • Enables secure integration of external authentication services

  • Reduces the attack surface through an explicit whitelist strategy

  • Prevents unauthorized redirects from unknown domains

  • Supports compliance requirements through documented trust relationships

  • Combined with CSRF protection for multi-layered security

Note:

  • Every registered domain is treated as trusted

  • Compromised registered domains can endanger the portal

  • A whitelist that is too permissive weakens CSRF protection

  • Incorrectly configured entries can block legitimate logins

  • Wildcards or patterns are not supported—each domain must be explicitly entered

Data protection assessment: - External authentication services process login credentials - review data protection agreements - Document the registered domains for data protection audits - Inform users about the external login services used

Recommendation: Enter only absolutely necessary domains. Use only trusted, established authentication services. Document each entered domain with justification and regularly check whether all entries are still necessary.

Practical example

Initial situation: You have enabled ANTICROSSSITEREQUESTFORGERY and use Azure Active Directory for user login. After logging in to Microsoft, users are blocked and receive an error message because the portal interprets the redirect from login.microsoftonline.com as a potential CSRF attack.

Configuration: ALLOWEDREFERERS = https://login.microsoftonline.com

After the change:

  • Users click on "Sign in with Microsoft"

  • The portal redirects to login.microsoftonline.com

  • Users log in to Microsoft

  • Microsoft redirects back to the portal

  • The portal checks the Referer header and finds login.microsoftonline.com

  • The domain is listed in ALLOWEDREFERERS

  • The request is accepted and the user is successfully logged in

Result: The Azure login works flawlessly, while CSRF protection remains active for all other requests. Attacks from unlisted domains continue to be blocked.

Alternative scenarios:

Scenario A - Multiple authentication services:

  • ALLOWEDREFERERS = https://login.microsoftonline.com,https://accounts.google.com

  • Support for Microsoft and Google login

  • Both services can securely send requests back to the portal

Scenario B - Partner portal integration:

  • ALLOWEDREFERERS = https://login.microsoftonline.com,https://partner.example.com

  • Azure Login and integration with partner system

  • Both systems can redirect users to the portal

Recommended setting

For standard installations: Depends on the services used

Reason:

  • The value must be adjusted to the external services actually in use

  • No universal default configuration is possible

  • Enter only necessary domains (principle of least privilege)

  • Regular review and updating required

Typical configurations:

  • Azure AD only:https://login.microsoftonline.com

  • Azure AD + Google:https://login.microsoftonline.com,https://accounts.google.com

  • No external services:"" (empty)

  • Azure AD + Partner Portal:https://login.microsoftonline.com,https://partner.domain.com

Tip: Document each registered domain in a configuration document with the following information: - Domain URL - Purpose/use (e.g., "Azure AD Login") - Responsible person/team - Date of registration - Date of last review

Review the list at least once a year and remove entries that are no longer needed.

War dieser Artikel hilfreich?