Contrib.social

Change form element access bypass default to FALSE on programmatic submissions.

Open on Drupal.org →
Created on 31 March 2014, over 11 years ago
Updated 28 March 2025, 5 months ago

Problem/Motivation

In #2174443: Add security hardening protection option for programmatic form submission → , a form-attribute is added to forms allowing programmatic form submissions (drupal_submit_form(), \Drupal->formBuilder()->submitForm()) to bypass access checks on form elements (prior to this change, access checks were always by-passed for programmatically submitted forms, see SA-CORE-2014-001 - Drupal core - Multiple vulnerabilities → ). The default value for this attribute is TRUE. Using FALSE as default, and forcing module developers to explicitly indicate that they wish to override the access checks, would be a more secure default.

Postponed until #2174443: Add security hardening protection option for programmatic form submission → lands.

Proposed resolution

Change the default value for the programmatic form submission access bypass setting (programmed_bypass_access_check) on forms to FALSE.

User interface changes

None.

API changes

Module developers wishing to retain current behavior (access bypass) for programmatic form submissions will need to add programmed_bypass_access_check => TRUE to their forms.

📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

forms system

Created by

🇧🇪Belgium mr.baileys 🇧🇪 (Ghent)

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 5 months ago →
    🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • Status changed to Needs work about 2 months ago
  • Comment about 2 months ago →
    🇺🇸United States smustgrave

    Seems to actually still potentially need to be relevant.

  • First commit to issue fork.
  • Merge request !12690Adapt patch from comment 1 → (Open) created by prudloff
  • Pipeline finished with Canceled
    about 2 months ago
    Total: 393s
    #544547
  • Pipeline finished with Success
    about 2 months ago
    Total: 770s
    #544550
  • Comment about 2 months ago →
    🇫🇷France prudloff Lille

    I opened a MR based on the old patch.

  • Comment about 2 months ago →
    🇺🇸United States smustgrave

    Think this will probably need a CR?

  • Comment 1 day ago →
    🇺🇸United States smustgrave

    So another thought is should we be doing the deprecating dance that in 12 it will default to xyz?

    At min think we will need a CR.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024