Removing the polyfill-fastly.io library of webform.libraries.yml

Created on 2 July 2024, 6 months ago
Updated 12 September 2024, 3 months ago

Problem/Motivation

The main issue is the need to remove the polyfill-fastly.io library from the webform.libraries.yml file. If it is not completely removed, it appears in the CSP module as an auto source, which poses a security risk.

Currently version 6.2.3 removes the library, but since it is still named in the webform libraries file, it is included by default in CSP.

Steps to reproduce

  1. Check the current webform.libraries.yml file to see if the polyfill.io library is included.
  2. Observe the CSP module and notice that the polyfill.io library appears as an auto source.
  3. Understand that this auto source is flagged as a security issue.

Proposed resolution

The proposed resolution is to completely remove the polyfill-fastly.io library from the webform.libraries.yml file to prevent it from appearing in the CSP module and mitigate the security risk.

Remaining tasks

  1. Remove the polyfill.io library entry from webform.libraries.yml.
  2. Update the webform module to reflect this change.
  3. Test the webform module to ensure it functions correctly without the polyfill-fastly.io library.
  4. Verify that the polyfill.io library no longer appears in the CSP module as an auto source.

User interface changes

There should be no user interface changes as a result of this resolution. The removal of the polyfill.io library is a backend change.

API changes

There are no API changes expected with this resolution. The removal of the polyfill.io library does not affect the API.

Data model changes

No data model changes are anticipated. This resolution involves only the removal of a library from the webform.libraries.yml file.

πŸ“Œ Task
Status

Fixed

Version

6.3

Component

Code

Created by

πŸ‡¨πŸ‡·Costa Rica thony1199

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

  • Issue created by @thony1199
  • πŸ‡¨πŸ‡·Costa Rica thony1199

    The following change removes the polyfill.io library from the webform.libraries.yml file. This library was being included for older browser support, specifically Internet Explorer 11 and earlier. The removal of this polyfill is necessary to address a security concern where it appears as an auto source in the Content Security Policy (CSP) module, potentially exposing the application to security risks.

  • πŸ‡¨πŸ‡·Costa Rica thony1199
  • In what way is polyfill-fastly.io a security risk?

  • πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦

    I understand that the library is only there for compatibility with IE 11. Since that is no longer supported by Drupal core, it should be removed anyway.

  • That’s not a security reason, to be clear.

  • Status changed to RTBC 6 months ago
  • πŸ‡¨πŸ‡¦Canada RobLoach Earth

    What @thony1199 brought up originally is about using a strict Content Security Policy, which can block external network requests. It's best to bring down external libraries, and serve them directly through Drupal.

    Whether or not that's the primary concern, it does make sense to remove this library outright. Internet Explorer was retired two years ago on June 15, 2022, and is no longer supported by Drupal. The polyfill is no longer needed.

  • πŸ‡©πŸ‡°Denmark ressa Copenhagen

    I agree @Liam Morland and @RobLoach, removing the redundant Polyfill library makes sense. Leaflet and Geofield Map contrib modules recently removed it altogether, since it's not needed anyway.

    About using CDN's such as polyfill-fastly.io ... It is safe to use today, but what happens if Fastly is bought up and closed, goes bankrupt, or something else, and the domain is squatted in two years time, just like polyfill.io was ...

    As a general observation about managing script libraries, see for example Collapsiblock, which has decided to pragmatically include a needed library in the module, making life easier for the end user:

    As of 4.2.0 the slide-element library is now bundled into the built code. It is no longer necessary to mess around with CDNs or downloaded libraries.

    From #3392947-8: Update readme to reflect JS library download no longer required β†’ , see also https://git.drupalcode.org/project/collapsiblock#js-library.

    In my opinion, it would be prudent to revise the "Policy on 3rd party assets on Drupal.org > Third party libraries" page, which currently says:

    Having third party libraries that are hosted elsewhere on the Internet in the Drupal.org repo is strongly discouraged. [...].

    From https://www.drupal.org/node/422996#libraries β†’

    It could be relaxed a bit, to something like this:

    Third party libraries hosted elsewhere on the Internet can be included in the Drupal.org repo, though it's not recommended.

    As I see it, it could ease the burden for module maintainers, and make life easier for module end users, if it wasn't strongly discouraged to include a small library in a contrib module.

    Alternatively, the Drupal community could make a handful of Composer packages for the most popular JavaScript libraries, so that module maintainers could require drupal/javascript-library-xyz making sure the end users always get the latest, safest version?

    Partially from #3426106-11: Polyfill.io is no longer considered safe and should be removed β†’ , where I got these very valid counter arguments by @mcdruid:

    Yeah it's a balance, and I don't think there's a clear "right answer" at present.

    Putting a static copy of the library in the module mitigates supply chain risk, but on the other hand if/when a vulnerability is found and fixed in the (upstream) library... we then need to find all copies of it everywhere and update them (or backport the fix).

    Which problem is worse?

    Referencing dependencies with tools like composer (and perhaps npm in the future?) has the advantage that it makes automated auditing easier (dependabot etc..) and potentially sites can update themselves without relying on Drupal projects doing new releases (that's subject to appropriate constraints being in place, and everyone's interpretation of semver agreeing etc.. etc..)

  • πŸ‡ΊπŸ‡¦Ukraine t1mm1 Kiev

    Hi,

    added patch for 6.2.7

  • Status changed to Fixed 3 months ago
  • πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024