A form could expose its contents in the page URL.

Actual scope of the review

Website HTML and JavaScript, Azure hosting configuration, domains, environments, application setting names and role assignments visible to the session. Azure reads were limited to the website resource and applicable permissions. Secret values were not used for the audit.

The form appears on the contact and audit request pages. Its only purpose is to prepare a draft in the visitor’s email app. There is no intended endpoint for collecting form data.

Failure tests used a local copy and synthetic text. Public checks were limited to non-destructive HTTP reads. No third-party system, client database or load test was in scope.

Confirmed finding: the browser’s default behaviour

The original form specified neither method nor action. JavaScript normally intercepted submission to open a mailto URL. If that script was blocked or unavailable, the browser could make a GET request to the current page with field values in the query string.

/before.html?need=application&message=AUDIT-SYNTHETIQUE-AUCUNE-DONNEE-REELLE&timing=&budget=

This URL was observed in the local browser after filling and submitting the real form code with scripts removed to simulate their unavailability.

Impact and conditions

A confidentiality risk under specific conditions, with a moderate remediation priority. Text entered in the form could appear in browser history and in request logs on systems that handle the URL. Copying the link could also share that text. The request still goes to the INOBIC website; no transfer to a third party was demonstrated.

The necessary condition is failure of the JavaScript handler followed by a submission containing data. No evidence of a past leak or actual log access was collected. No numeric CVSS score is assigned without fuller context analysis.

A three-layer fix

1. Fail-closed initialisation: the form is hidden in HTML and revealed only after handlers are installed. Hiding does not rely solely on a potentially cached stylesheet.
2. Explicit HTML behaviour: POST replaces the implicit GET. The normal handler continues preventing native submission and preparing the email.
3. HTTP response protection: the CSP form-action none directive blocks HTML submissions even if the form becomes visible without its handler.

A direct email link stays visible without JavaScript. A version is added to the script URL to avoid reusing a stale copy. Draft line breaks, previously literal characters, were also fixed.

Testing the fixes

• Before: the synthetic marker appears in the URL after submission without scripts.
• After, without scripts: the form stays hidden and direct email contact remains available.
• After, normal operation: the form is visible, need selection is preserved, the summary can be copied, line breaks are real and text does not appear in the HTTP URL.
• Defence in depth: a local test deliberately makes the form visible without its JavaScript handler; CSP blocks the browser’s default form submission.
• Automated tests: encoding, prevention of default form submission, initialisation order, successful copying and manual copying when clipboard access is denied.

These tests do not cover all browsers or email delivery. No message was sent during validation.

Other checks and limitations

The reviewed site inventory contained only two application JavaScript files and no third-party JavaScript dependency. No dynamic HTML sink or eval call was found in them. Targeted secret checks returned no findings; they do not replace a full history review.

Five targeted configuration, repository and API paths returned 404. The website’s Azure domains were valid and no application settings were configured on that resource. These observations do not establish that no files are exposed.

CSP also restricts scripts, connections and frames. Inline styles remain allowed to preserve existing pages; this is an explicitly retained limitation. Unused browser feature permissions are disabled.

Inherited permissions used to administer Azure need a least-privilege review. Details remain in the private report; no subscription permission was changed during this engagement. The review does not cover the entire Entra ID tenant.

Redacted evidence and reproduction steps

Published material contains only public website code, synthetic data, configuration diffs and test results. Subscription IDs, users, access and session information are excluded.

Download the case files and reproduction tools

• Test results and scope
• JavaScript fix diff
• HTTP security configuration diff
• Evidence hashes

Define the scope of an application review →

Evidence-backed audit practices

Written authorisation, risk-based checks, collection of only the evidence needed, and verification of fixes. Our method also records checks that were not performed and risks that remain unresolved.