highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.HTML formsWhere it livesImplementationThis fix is applied in: HTML forms. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Insecure form action: submit over https, never cleartext http

Serve the page and its form over https so nothing a visitor types is sent in cleartext

The threat

The scanner found a <form> whose action points at an http:// URL (or a form on a page served over http that posts back to itself). The finding is straightforward: when a visitor submits that form, the browser sends everything they typed over an unencrypted connection.

It does not matter how careful the rest of your site is. The moment that form is submitted, the field values (a contact message, a password, a card number) travel across the network in plain text. Anyone sharing that network path (the coffee-shop wifi, the ISP, a compromised router) can read them, and browsers now warn the visitor “the information you are about to submit is not secure” right at the point of sale.

The exact fix

Two things must be true, and you need both: the page is served over https, and the form’s action is an https URL.

1. Point the form action at https, or make it a relative path, which inherits the page’s scheme:

<!-- before -->
<form action="http://yourdomain.com/subscribe" method="post"> ... </form>

<!-- after: absolute https, or just a relative path -->
<form action="https://yourdomain.com/subscribe" method="post"> ... </form>
<form action="/subscribe" method="post"> ... </form>

A relative action like /subscribe is the most robust option: it always posts over whatever scheme the page itself loaded with, so once the page is https, the submission is too.

2. Serve the page over https and redirect http to https, so the form is never delivered over cleartext in the first place. On Netlify this is automatic: turn on Force HTTPS in Domain settings. On nginx:

server {
  listen 80;
  server_name yourdomain.com;
  return 301 https://$host$request_uri;
}

3. Add a CSPCSPHTTP headerContent-Security-Policy: a response header that whitelists exactly which scripts, styles, images and connections a page may use, so an injected payload simply has no permission to run. backstop that upgrades any stray http subresource or action, so one you miss cannot silently downgrade:

Content-Security-Policy: upgrade-insecure-requests

A relative action is not enough on its own. If the page is still reachable over http, an attacker can keep the visitor there and the relative form will post over http too. That is why step 2, forcing https on the page, is not optional: the two fixes only work together.

Verify it

curl -s https://yourdomain.com/ | grep -i '<form'

Every action you see should be https://... or a relative path (starting with /), never http://. Then load the page, open DevTools on the Network tab, and submit: the request should go to an https:// URL with no mixed-content or “not secure” warning.

Proof

The ApeCyber scanner reads this straight from your page’s HTML on a normal passive scan, from the outside, spotting the http:// in a form action without ever submitting anything, touching nothing. apecyber.com serves every page and form over https on Netlify, part of the posture behind its A / 100, a clean −20 once no form can post in the clear.