Power Pages HTTP Headers & Site Settings Explained

• Site Setting: HTTP/Content-Security-Policy
• Recommended Setting/Value: CSP is off by default, can be turned on to enhance security. Will need to specify which directive values needed separated by a semicolons (;). It is recommended to enable and use the HTTP/Content-Security-Policy-Report-Only initially as this allows the policy to be monitored but not enforced.
• Documentation: https://learn.microsoft.com/en-us/power-pages/security/manage-content-security-policy

Content Security Policy (CSP) is a security standard designed to add an additional layer of security for web applications. It allows developers to restrict which resources (such as JavaScript, CSS, Images, and others) can be loaded. This helps reduce the risk of cross-site scripting (XSS), clickjacking, and other code injection attacks.

CSP Directives:
One or more 'directives' are combined to make up the CSP header, directives are instructions or rules that define what can/cannot be done with each directive defining a specific type of resource. There are many CSP directives which can be found here: CSP reference, noting that several security-related directives are noted within this blog.

When CSP is turned on for a Power Pages site, it helps to make the site more secure by blocking connections, scripts, fonts, and other types of resources that originate from unknown or malicious sources. CSP can be configured via the Portal Management app, setting the values required from the CSP reference, separated by semicolons. For example, script-src 'self'; style-src 'self'.

How CSP Works:

When a Power Pages web page is loaded, the browser checks if a CSP header is present. If so, it enforces the specified restrictions on content loading and execution. This prevents the execution of malicious scripts and helps mitigate the impact of code injection vulnerabilities. A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser’s trust in the content received from the server. Malicious scripts are executed by the victim’s browser because the browser trusts the source of the content, even when it’s not coming from where it seems to be coming from. CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts.

• Site Setting: HTTP/Content-Security-Policy
• Recommended Setting/Value: `script-src 'self' content.powerapps.com 'nonce' (for a strict policy that does not allow scripts to load from sources outside of Power Pages site) OR script-src https: 'nonce' (to load scripts from any secure source).
• Documentation: https://learn.microsoft.com/en-us/power-pages/security/manage-content-security-policy#turn-on-nonce

A nonce is a unique cryptographic code that is designed to be used once ("number once" = nonce). When a nonce is directive is used within a Power Pages site's CSP, a unique cryptographic code is generated and added to each script that's specified in the CSP header. Only inline scripts that have a nonce attribute that matches the one in the CSP are allowed to run. Scripts that an attacker may have injected into the page are blocked because they don't include the nonce attribute. This helps to prevent Cross-Site Scripting (XSS) attack where an attacker might inject malicious code into your website.

The Script-src directive is used to control which external scripts can be loaded, inline script event handlers (on-click) and XSLT stylesheets which can trigger script executions.

Additionally, when nonce is enabled in Power Pages, the 'unsafe-eval' directive is automatically added to allow the automatic evaluation of unsafe code (HTTP/Content-Security-Policy/Inject-unsafe-evalset to False). Unsafe-eval can be turned disabled (set to True , however the validation of fields on basic or multistep forms may not function correctly.

In Power Pages sites, nonce only supports inline scripts and inline event handlers.

If you configure both Content-Security-Policy frame-ancestors and X-Frame-Options, the browser will prioritize the Content-Security-Policy frame-ancestors directive. This is because frame-ancestors is a more modern and flexible directive that has superseded X-Frame-Options.

According to the Content Security Policy Level 2 specification, if a resource has both policies, the frame-ancestors policy should be enforced and the X-Frame-Options policy should be ignored. This is because frame-ancestors provides more granular control, allowing you to specify multiple trusted domains.

Some older browsers do not support Content-Security-Policy, in these cases they will fall back to the X-Frame-Option. Therefore, if compatibility issues with older browsers is important, then ensure that the frame-ancestors and X-Frame-Options policies match if you decide to use both. 

WARNING: Older browsers such as Internet Explorer often have other vulnerabilities and should be avoided. It is best practice to use modern-browsers.

• Site Setting: HTTP/Content-Security-Policy
• Recommended Setting/Value: frame-ancestors 'self' <website> (default, allows Power Pages site to embed its own pages) OR frame-ancestors 'none' (deny all embedding). Avoid using wildcard (*) and limit embedding to specific sites - always test on non-production for troubleshooting.
• Documentation: https://learn.microsoft.com/en-us/power-pages/configure/embed-website

Prevents content from your Power Pages website (frame, iframe, object, embed, applet, etc) being used in a Clickjack attack. Clickjack attacks occur when a malicious website overlays malicious transparent layers over legitimate content (ie, from your website such as a video, information, etc) in their webpage to try and to get users to click on malicious links or buttons.

Because the frame-ancestor directive allows for greater granularity over which website are allowed to embed content from your Power Pages site, it is preferred over the HTTP/X-Frame-Option. That is, X-Frame-Option only allows you to specify if your content can be embedded on the same domain or not at all, whereas the frame-ancestor directive allows an allowed list of trusted domains.

The syntax for setting the frame-ancestors directive is: Content-Security-Policy: frame-ancestors <source>; Where <source> can be:

'none': No URLs match and all embedding is blocked, regardless of domain name (including self).

'self'' (default): Refers to the origin from which the protected document is being served, including the same URL scheme.

<scheme-source>: A scheme such as http: or https:.

<host-source>: Internet hosts by name or IP address, as well as an optional URL scheme and/or port number.

WARNING: It is possible to also allow data: URLs as content source but is not recommended as it is insecure and allows attackers to inject malicious and arbitrary data URLs. Refer to the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors documentation for more information on setting the directive.

Example of clickjack attack:
An attacker creates a malicious webpage that embeds your Power Pages log-in page in an iframe. They have used very similar domain name (one letter different or similar) thus creating a deceptive duplicate. The attacker has overlayed transparent/invisible buttons and fields over the legitimate ones, so when a user enters their log-in details, they are actually entering it into the attackers' fields where they are captured. When the user clicks on the "log-in" button, they are actually clicking on a transparent button overlayed that downloads a spyware onto the user's machine before redirecting the user to your legitimate Power Pages log-in. The user just thinks the redirect was a glitch, and then logs into your legitimate Power Pages website, unaware that their log-in credentials have been stolen and spyware was installed onto their devices.

• Site Setting: HTTP/X-Frame-Options
• Recommended Setting/Value: SAMEORIGIN or DENY(note, it is better to use Content-Security-Policy Frame-ancestors site setting)
• Documentation: https://learn.microsoft.com/en-us/power-pages/configure/embed-website

Prevents content from your Power Pages website being used in a Clickjack attack. Clickjack attacks occur when a malicious website overlays malicious transparent layers over legitimate content (ie, from your website such as a video, information, etc) in their webpage to try and to get users to click on malicious links or buttons. The X-Frame-Options is a HTTP response header that is used to tell a browser if it is allowed to render content from your webpage as a <frame>, <iframe>, <embed> or <object> (these are HTML tags that tell the website what to display, this is where your content would be added). This helps your Power Pages website avoid clickjack attacks by ensuring your content is not embedded into another [malicious] webpage. The X-Frame-Option does not prevent static content such a logos from being copied. Microsoft notes that this security is only provided if the user accessing the document is using a browser that supports X-Frame-Options (usually an older browser).

DENY - When the X-Frame-Option is set to DENY, the content from your website cannot be displayed in a frame on any website. This may prevent content from one page displaying in another webpage within your Power Pages website.

SAMEORIGIN - When the X-Frame-Option is set to SAMEORIGIN, it means your webpage and the content within it can only be framed (displayed) by a page from the same domain origin (i.e., your Power Pages domain). So, your Power Pages site can display content on different webpages, but nowhere else.

• Site Setting: DisableValidationWebTemplate
• Recommended Setting/Value: FALSE (default)
• Documentation: https://learn.microsoft.com/en-us/power-pages/configure/basic-forms#request-validation

Request Validation ensures that user input to a server is encoded to ensures that any HTML tags are treated as text rather than part of the HTML document structure or if raw unencoded HTML is entered into a field the result will be an error message. This process is known as HTML encoding and helps maintain the security, integrity, and usability of web applications. HTML encoding helps to prevent a server from accepting content containing un-encoded HTML which can include malicious scripts and tags.

Malicious Scripts - Malicious code can be submitted and stored on a server and then presented to other users resulting in Cross-Site Scripting (XSS) and other Script Injection attacks. When the malicious script is displayed to other users on your Power Portals webpage (i.e., if request validation is turned disabled), the script is executed and can lead to various harmful outcomes such as stealing sensitive data. To prevent XSS, it is common coding practice to encode user input on the server side to ensure that any HTML tags are treated as text rather than part of the HTML document structure.

Malicious Tags - Unencoded HTML tags can unintentionally disrupt the page layout or functionality. If users are allowed to input un-encoded HTML, they might unintentionally include HTML tags (especially less tech-savvy users). This could lead to their input not being displayed as they intended.

An organisation may want to turn off Request Validation to use a rich text editor.

WARNING - when changing the site setting DisableValidationWebTemplate to TRUE, you will be allowing unencoded HTML for the entire Power Pages Site (all web pages within that site). Nicholas Hyduke from Engineered Code suggests "the alternative approach is to encode the data before it is sent to the web server for processing, then use a CDS plugin to decode the data so that it is saved as proper HTML", please see his blog post to learn more: https://www.engineeredcode.com/blog/power-apps-portals-rich-text-editor-on-entity-forms

• Site Setting: HTTP/X-Content-Type-Option
• Recommended Setting/Value: nosniff
• Documentation: https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/gg622941(v=vs.85)?redirectedfrom=MSDN

MIME (Multipurpose Internet Mail Exchange) is used to allow a computer to know what type of data is in a file such as a text, audio, video, application etc. When the browser asks the server for a file, the server will tell the browser what kind of file it is (HTML, jpeg etc) using MIME types in the HTTP header. More technically, it is a supplementary protocol that allows non-ASCII data to be sent via SMTP.

User agents, such as browsers, commonly attempt to guess the resource type being requested through a process called MIME type sniffing. This can potentially lead to security vulnerabilities, as it could transform non-executable MIME types into executable MIME types. When misused, MIME types can result in XXS and malicious code execution (attacker tricks browser into executing script that has been uploaded and disguised as benign files exploiting MIME mismatch), content injection (malicious content such as malware, can be injected into a webpage) -- all these attacks exploit the browsers MIME sniffing behaviour.

When the X-Content-Type-Options is set to 'nosniff', the browser is prevented from trying to guess and change what type of file it thinks it is receiving and to trust the MIME type that the server has specified. This helps to prevent an attacker from tricking the browser into misinterpreting the file type and providing greater security to Power Pages sites.