Payment-related form posts to an explicit HTTP address
ShipReady found a payment-related form whose action explicitly begins with HTTP rather than HTTPS.
Why it matters
An explicit HTTP form action can send submitted payment-related data over an unencrypted network connection, even if the page itself was reached over HTTPS.
How ShipReady detects it
What it inspects
ShipReady examines server-delivered HTML forms for an explicit HTTP action. It limits the check to forms containing card-field signals or posting to a known payment provider or checkout-looking destination.
What triggers a finding
The rule triggers when a qualifying form action literally starts with HTTP.
What the evidence shows
The observed markup contains a qualifying form that names an explicit HTTP submission address.
Limits of this check
ShipReady does not submit the form, capture traffic, inspect redirects after submission, or assess every dynamically generated form. It does not report a relative action merely because a page might be available over HTTP.
How to fix it
Use the HTTPS endpoint
Change the deployed form action to the intended HTTPS endpoint and remove any HTTP payment endpoint from the application configuration.
Enforce secure transport at the edge
Configure HTTPS for the destination and redirect or reject plain HTTP requests where appropriate.
How to verify the change
Verify the deployed form action
Inspect the production markup and a controlled browser submission to confirm the target URL is HTTPS.
Expected: The qualifying form submits only to the intended HTTPS endpoint.