Password form declares an explicit HTTP submission endpoint
ShipReady found a static password form whose action explicitly names a non-local HTTP endpoint.
Why it matters
A password form's declared submission endpoint is worth reviewing carefully. This finding identifies static markup that names HTTP; it does not submit the form or establish how an application or browser ultimately handles credentials.
How ShipReady detects it
What it inspects
ShipReady scans static HTML from a readable, content-serving response for forms outside template blocks that contain an input with type=password.
What triggers a finding
The rule triggers when a matching form has an action beginning with HTTP, case-insensitively, and that action is not localhost or a loopback development host. The form method does not affect this rule.
What the evidence shows
Static page markup declared a password form with an explicit non-local HTTP action endpoint.
Limits of this check
ShipReady does not submit the form, execute JavaScript, inspect server-side handling, capture credentials, or prove that a user sent a password. Relative, protocol-relative, absent, inert, and local development actions do not trigger this rule; forms inside template elements are excluded.
How to fix it
Review the declared credential endpoint
Confirm the form's intended action and configure it to use the appropriate HTTPS endpoint. Review the relevant proxy and application routing at the same time.
Test the real login flow
Test the deployed form in supported browsers and inspect the actual request chain. ShipReady does not perform this runtime test.
How to verify the change
Verify the deployed action
Inspect the deployed form markup and test the intended sign-in flow in a controlled environment.
Expected: The intended password form no longer declares a non-local HTTP action, and the tested login flow uses the intended endpoint.