Quick summary
A WordPress support note about tracing a form editor's 403 response to the firewall, adding a narrowly scoped exception, and correcting the replacement embed's responsive width.
The problem
A form-script widget could not be edited because the firewall rejected its external embed code, and the replacement form rendered at a browser-default narrow iframe width.
What I checked
- The failing WordPress AJAX request and returned 403 response
- Firewall activity and the exact blocked POST parameter
- Original and replacement form embed markup
- Iframe sizing inside the page-builder column
- Live desktop and mobile form behavior
What I changed
- Added an allowlist rule for only the required POST parameter
- Kept the rest of the firewall protection active
- Updated the iframe styling to fill its available container
- Published and verified the form fields, consent copy, button, and responsive layout
Result
The editor works again without weakening the firewall broadly, and the embedded form now uses the full available width across screen sizes.
Where this fix usually leads next
This kind of work usually connects back to WordPress Support and Website Fixes so the fix note can lead into a clearer support path instead of staying as an isolated one-off task.
What I'd watch next
- Whether the embed vendor changes the submitted parameter format
- Whether a firewall ruleset update overrides the exception
- Whether the form provider adds its own responsive sizing