Idea Summary
Introduce a built‑in CSRF‑token mechanism in Oracle APEX that automatically adds and validates a cryptographically strong, per‑session token in every HTML form—even those rendered by the APEX engine itself (e.g. the default <form id="wwvFlowForm">). The feature would:

• Generate a unique, high‑entropy token at session start and store it server‑side.
• Inject a hidden field (configurable name, e.g. __RequestVerificationToken) into all forms (<input type="hidden" name="…">).
• Validate the token on every POST (and other state‑changing) request before processing.
• Allow parameter‑name customization to satisfy different security scanners’ known token‑name patterns.

This would eliminate “No Anti‑CSRF Tokens” alerts from tools like OWASP ZAP and ensure out‑of‑the‑box protection for all pages, including login and custom PL/SQL‑based forms.

Use Case

• Default APEX Applications: Protect the built‑in login form and any forms generated by APEX wizards without manual intervention, closing a gap where tools flag missing tokens in the default wwv_flow form.
• Custom PL/SQL Processes: Give developers a simple API (e.g. APEX_SECURITY.GET_CSRF_TOKEN / APEX_SECURITY.VALIDATE_CSRF_TOKEN) so that custom PL/SQL forms can leverage the same mechanism.
• Compliance and Scanning: Eliminate medium/high OWASP ZAP alerts (“No Anti‑CSRF Tokens”) by providing a token name recognized by scanning tools (e.g. __RequestVerificationToken, X-CSRF-Token, OWASP_CSRFTOKEN)
• AJAX & REST Endpoints: Extend support so that AJAX calls can send the token in a custom header (e.g. X-CSRF-Token) or JSON payload, following OWASP’s recommendation to leverage headers for stronger isolation

Preferred Solution

1. New Security Attribute
   • Add a toggle under Shared Components → Security Attributes: “Enable CSRF Token Protection”.
2. Token Generation & Storage
   • On session creation, generate a cryptographically secure random token (e.g. 256‑bit) and store it in the APEX session table.
3. Form Injection

   • Enhance the APEX rendering engine (wwv_flow.accept) to insert:

     <input type="hidden" 
           name="__RequestVerificationToken" 
           value="&CSRF_TOKEN." />
     (Name is configurable in the security attributes.)

   • Server‑Side Validation

     • Before any PL/SQL process or page submission, validate the incoming token against the stored session token. If missing or mismatched, reject the request with HTTP 403.

   • Developer API

     • Provide PL/SQL wrappers:

       l_token := APEX_SECURITY.GET_CSRF_TOKEN;
       APEX_ITEM.HIDDEN('CSRF_TOKEN', l_token);
        

       BEGIN
        APEX_SECURITY.VALIDATE_CSRF_TOKEN(:CSRF_TOKEN);
       EXCEPTION WHEN OTHERS THEN
        APEX_UTIL.HTTP_RESPOND(403, 'Invalid CSRF Token');
       END;
        

     • Parameter‑Name Mapping

       • Allow mapping of existing hidden parameters (e.g. pPageSubmissionId or pSalt) to scanner‑friendly names, or deprecate them in favor of the standard token name to fix false positives in tools like ZAP

     • AJAX/REST Support

       • For apex.server.process and ORDS‑based REST endpoints, accept the token via the configured header (default X-CSRF-Token) following OWASP’s header pattern recommendation

       Implementing this feature would provide developers with turn‑key CSRF protection, improve out‑of‑the‑box security, and immediately satisfy automated security scanning requirements.