Loading AddToAny with a content security policy in .htaccess

Created on 7 February 2023, almost 2 years ago
Updated 21 March 2023, over 1 year ago

Problem/Motivation

Hi everyone,
Here is to report back a security concern of transferring JavaScript content with unsecure protocol.
The module requires access to developer webpage to get necessary Javascripts and the content access is not possible with secure http (https) which in 2023 it is counted as a security threat.

Utilize htaccess to define secure access channels of https has been used but the browser issues warning over blocking of http;//content access, so it is a requirement to access the site in an unsafe manner.

Steps to reproduce

Install Drupal
Install module
Add https protocol as only trusted protocol channel in htaccess.
Review blocked scripts in the browser development mode.

Proposed resolution

Providing an option to Enforce secure connection over http to get external scripts and API access.
Hope this report add intrinsic security to all aspect of Drupal development and makes Drupal community secure.

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Closed: works as designed

Version

2.0

Component

Code

Created by

🇮🇷Iran tsotoodeh

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @tsotoodeh
  • Status changed to Closed: cannot reproduce almost 2 years ago
  • 🇺🇸United States micropat

    The module already loads AddToAny using HTTPS.

    AddToAny is secure by default and HSTS preloaded in browsers to ensure it loads over HTTPS only.

  • Status changed to Needs review almost 2 years ago
  • 🇮🇷Iran tsotoodeh

    Sure, there is a saying and there is a motivation for this post discussion!
    Could you kindly have a look at the supporting evidence attached to this post.
    The screenshot of content security policy section of browser which proves an issue of loading in-secure content.

  • Status changed to Active almost 2 years ago
  • 🇺🇸United States micropat

    How are you implementing your CSP?

    The report in the screenshot is erroneously showing http: for some reason. What tool is that report from?

    AddToAny has general guidance on working with a strict CSP where a nonce is the recommended usage:
    https://www.addtoany.com/buttons/faq/#content-security-policy

    In the Drupal ecosystem it seems that nonces aren't straightforward to implement yet ( csp module , seckit module Implement a "semi automatic" Nonce settings Needs work ), so you'll probably want to include https://*.addtoany.com in an allowlist to generate something like the following HTML meta tag:

    <meta http-equiv="Content-Security-Policy"
      content="default-src 'unsafe-inline' https://*.addtoany.com https://*.pinterest.com; img-src 'self' data:">
  • 🇮🇷Iran tsotoodeh

    Well, Well, Well. Content security policy is inserted in htaccess at the root level. This approach helps with minimizing load request, centralizing security controls, and downsizing maintenance tasks, in comparison with adding meta tags to all pages via a third-party module or directly in theme files.

    How are you implementing your CSP?

    The backing evidence provided by Opera and if you are thinking of a false positive please feel free to set it up and reproduce the result. It is expected from the module to request all the content from a secure channel, no matter the security implementation approach of a site is? How do you agree on this?

  • 🇺🇸United States micropat

    Since the site isn't using nonces, the CSP header needs to be updated to explicitly allow domains such as https://*.addtoany.com (and https://*.pinterest.com if Pinterest is wanted).

    In .htaccess it should look something like:

    Header add Content-Security-Policy "default-src 'unsafe-inline' https://*.addtoany.com https://*.pinterest.com; img-src 'self' data:;"

  • Status changed to Closed: works as designed over 1 year ago
Production build 0.71.5 2024