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.
Change the default value for the programmatic form submission access bypass setting (programmed_bypass_access_check) on forms to FALSE.
None.
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.
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #1
mr.baileysComment #2
mr.baileys#2174443: Add security hardening protection option for programmatic form submission has landed, so no longer postponed.
Comment #18
smustgrave commentedThank 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!
Comment #19
smustgrave commentedSeems to actually still potentially need to be relevant.
Comment #22
prudloff commentedI opened a MR based on the old patch.
Comment #23
smustgrave commentedThink this will probably need a CR?
Comment #24
smustgrave commentedSo 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.
Comment #25
prudloff commentedI drafted a CR.
Comment #26
smustgrave commentedThanks believe this one is good to go, pipeline is green and CR reads fine (to me at least)
Comment #28
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #29
smustgrave commentedBot rebellion
Comment #30
longwaveIs there a way we can do this by triggering a deprecation for now, then changing the default behaviour in the future? Otherwise this is a BC break for anyone relying on this working the way it currently does.
Comment #31
smustgrave commentedMaybe could do something like static.cache where we show a warning on the status report? Else not sure how the deprecation would get picked up?