Password form declares an explicit GET submission
ShipReady found static password-form markup with method=GET and a meaningful explicit action.
Why it matters
An explicit GET form declaration carrying a password field is a configuration signal to review. If a browser submits such a form conventionally, its field values can become part of the request URL; ShipReady does not perform that submission.
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 only when the form explicitly specifies method=get, case-insensitively after trimming, and has a meaningful explicit action. Missing actions, empty and inert actions, and javascript actions are excluded.
What the evidence shows
Static page markup declared a password form with an explicit GET method and a meaningful action endpoint.
Limits of this check
ShipReady does not submit the form, inspect JavaScript interception or endpoint behavior, observe submitted values, browser history, logs, referrers, or URL leakage. It does not treat omitted form methods as GET findings, because those forms may be handled by JavaScript; forms inside template elements are excluded.
How to fix it
Review the form's intended submission method
Confirm whether the form is intended to navigate with GET. For a credential submission that should not use a URL query, configure the form and receiving endpoint for the appropriate non-GET flow.
Test deployed submission behavior
Test the form's real client-side and server-side behavior after the change. ShipReady does not inspect JavaScript interception or submit the form.
How to verify the change
Verify the deployed form
Inspect the deployed form attributes and test the intended sign-in workflow in a controlled environment.
Expected: The password form has the intended submission method and action, and the tested flow behaves as designed.