docs: warn about front-end-only required field validation and known bugs

docs/conditional-validation.md

@@ -2,6 +2,12 @@
 
 The **Conditional Validation** works in the same fasion as the [Conditional Logic](conditional-logic) does except that this is used for throwing an error message for a specific field whenever the selected condition(s) did not match.
 
+> ⚠️ **Browser-only feature — no server-side equivalent**
+>
+> Conditional Validation (including the conditional-required `may_be_empty = conditions` feature introduced in v4.9.0) is implemented entirely in front-end JavaScript. It requires a modern browser with JavaScript enabled.
+>
+> There is **no server-side equivalent**: a user who submits via a crafted HTTP POST request bypasses all conditional-validation rules unconditionally. Do not rely on this feature alone to enforce data-integrity or security requirements on the server.
+
 **Example use case 1:**
 
 Let's say you let the user enter their age and you only allow users to submit the form who are 16 years or older.
@@ -14,6 +20,18 @@ Let's say you only want to allow users who are between 16 and 18 years old to re
 In this case we can use the `>= && <= Greater than or equal to AND Less than or equal to` condition and enter the number 16 for the first condition and the number 18 for the second.
 Now whenever a user enters the number 15 or below or either 19 or above it will display the error message to the user.
 
+## Conditional Required Fields (may_be_empty = conditions)
+
+Since **v4.9.0**, a field can be made conditionally required: it is only required when one or more conditions are true. This is configured by setting the field's "May be empty" option to `conditions` and defining the conditional logic rules.
+
+**How it works (browser-side):**
+The JavaScript engine evaluates the conditions at submit time. If the condition(s) match, the field is treated as required (`allowEmpty = false`); otherwise the field may be left blank.
+
+**Limitations:**
+- Requires JavaScript to be enabled in the browser.
+- Has no server-side equivalent — a crafted HTTP POST bypasses condition evaluation entirely.
+- The hidden-parent check (`has_hidden_parent`) inspects `data-conditional-action` attributes and the `super-conditional-hidden` class, but not the `super-hidden` class on parent shortcodes. A secondary guard inside `handle_validations` handles the latter case.
+
 _Below you can find all the possible conditional validation methods:_
 
 * ?? Contains

docs/validation.md

@@ -3,6 +3,12 @@
 The Validation option gives you the ability to quickly add a specific validation to any of your fields.
 This will decrease the risk of a user making mistakes or typos while filling out the form.
 
+> ⚠️ **Important Security Notice — Front-End-Only Enforcement**
+>
+> All field validation in Super Forms — including required-field checks — is currently enforced exclusively in the **browser via JavaScript** (`SUPER.validate_form` / `SUPER.handle_validations`). There is **no server-side fallback**.
+>
+> This means that users who disable JavaScript, or who craft a direct HTTP POST request, can bypass all required-field rules and submit the form with blank or invalid values. Until server-side validation is added, do not rely on front-end required-field rules as a security or data-integrity guarantee for sensitive forms.
+
 Below you can find the available validation methods:
 
 ## Letters only
@@ -18,6 +24,24 @@ Only allow input field to contain letters, and nothing else
 This is the most used validation method, it will simply check if the field was entered or not.<br />
 This allows you to make a field a so called **Required field***.
 
+### How required-field enforcement works
+
+When you mark a field as required, Super Forms sets a `may_be_empty` flag on the field element. The JavaScript validation engine reads this flag at submit time and raises an error if the field is empty.
+
+Fields that use the **"none" validation type** (the default) rely exclusively on the `may_be_empty` flag for required enforcement. The PHP shortcode layer intentionally omits the `data-validation` HTML attribute for these fields, which means the final JavaScript check at `common.js` line 4738 —
+
+```js
+if(typeof args.validation !== 'undefined' && !args.allowEmpty && args.emptyValue) error = true;
+```
+
+— is **never reached**, because `args.validation` is `undefined` for "none"-type fields. The required check for "none"-type fields is therefore handled in the earlier `may_be_empty` path (lines 4480–4505).
+
+> ⚠️ **Known bug (v6.3.3):** A required text field configured with the default settings (`validation = 'none'`, `may_be_empty = 'false'`) may silently pass blank-submit validation under certain conditions. No error is raised and the form proceeds to submission. This bug is tracked and will be addressed in a future release.
+
+### No server-side required-field validation
+
+The server-side submission handler (`class-ajax.php::submit_form_checks()`) validates only the honeypot, reCAPTCHA, i18n, and rate-limit locks. It contains **zero required-field assertions**. A direct HTTP POST with JavaScript disabled bypasses all required-field enforcement unconditionally.
+
 ## E-mail address
 
 This validation method checks if the entered email address was a possible valid