Site doesn’t force HTTPS
The plain http:// address of your site serves the page instead of redirecting to https://.
- Severity
- Medium
- Who can exploit it
- Anyone on the same network as a visitor, such as public Wi-Fi
- Found by
- PatchLabs Live posture: one plain http:// request to your home page
- Lab proof
- Not lab-proven: read from your site’s response
What it is
Forcing HTTPS means that when someone types or follows http://your-app.com, your server answers with a redirect (a 301 or 308) to https://your-app.com and nothing else. PL-027 means the plain http:// request got the page itself, or a redirect that lands on another http:// address.
Over plain HTTP, everything between the visitor and your server can read and change the page: the café Wi-Fi, a compromised router, anything on the path. Someone there can swap your sign-in form for their own, or inject a script that reads the session your app stores in the browser. The visitor sees your normal domain and no warning.
Why AI builders produce it
The big hosts redirect for you on their own domains, so the app works in every preview. The gap appears at launch: a custom domain added in a hurry, DNS pointed at a proxy set to “Flexible” TLS, or an old server left answering on port 80. Nobody types http:// by hand while testing, so nobody notices.
What we see
A synthetic example for app.example.com, shortened. Not taken from any real site.
$ curl -sI http://app.example.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
# no redirect: the whole page was sent over plain HTTPCheck it yourself
Ask for the plain address and look at the first line and the Location header. You want a 301 or 308 to an https:// address.
curl -sI http://your-app.com | head -n 5
# good: HTTP/1.1 308 Permanent Redirect
# Location: https://your-app.com/
# follow every hop and print where it ends up
curl -sIL -o /dev/null -w '%{url_effective}\n' http://your-app.comThe fix
The fix is a redirect from every http:// URL to the same path on https://, done by your host or proxy, not by JavaScript in the page (a script only runs after the page has already crossed the network in the clear).
Vercel
Vercel redirects HTTP to HTTPS on its own, including for custom domains, once the domain is added to the project and its certificate is issued. If the check fails on Vercel, the request probably isn’t reaching Vercel: look for an old A record or a proxy in front. In the project, open Settings → Domains and make sure every hostname you use (with and without www) is listed and shows a valid configuration.
Netlify
Netlify redirects HTTP to HTTPS automatically once a certificate is provisioned for the domain. If plain HTTP still serves the page, open Domain management → HTTPS and check the certificate covers every hostname you use; a domain waiting for DNS verification has no certificate and no redirect yet.
Cloudflare
In the dashboard, SSL/TLS → Edge Certificates, turn on Always Use HTTPS. On SSL/TLS → Overview, use Full (strict), not Flexible: Flexible sends the request on to your host over plain HTTP, and some hosts then redirect back, which loops.
Lovable
Lovable issues the certificate for a connected custom domain itself, according to its documentation. If the plain http:// address still serves the page and the domain goes through Cloudflare, turn on Always Use HTTPS there (see the Cloudflare tab). Otherwise, ask Lovable support, since its docs don’t describe a redirect setting.
Once the redirect works, add HSTS (PL-029) so browsers stop trying plain HTTP at all.
Live posture findings come with the header or setting to change. PatchLabs never changes your hosting or your repo.
How PatchLabs finds it
[HTTP] http://app.example.com/ 200 OK, no redirect FLAG [HTTPS] https://app.example.com/ → 200
Live posture sends one plain http:// request to your home page and reads only the status line and the Location header. A redirect that reaches https:// on the same site passes. Domains on a top-level domain that browsers already force to HTTPS (the HSTS preload list, such as .app and .dev) pass without the redirect, because no browser will load them over plain HTTP. It never follows other links or tries other paths. On the free headers check the same request is made for any address you type; in the app it runs only on a domain you verified.
When the pattern is intended
Almost never for a site with sign-in. A local network device or a test box with no certificate is the usual exception, and neither belongs on a public domain.
Why it’s rated medium
Medium: it needs someone on the visitor’s network path, but on shared Wi-Fi that is a low bar, and it undoes every other protection on the page. In the Live posture grade it costs 15 points.
Related findings
No HSTS header, or max-age under 180 days
Browsers aren’t told to use HTTPS only, so a visitor’s first request can still go out over plain HTTP.
PL-028TLS certificate is invalid, expired or expires within 21 days
Browsers will block your site, or soon will, because its HTTPS certificate doesn’t check out.
PL-034Page loads scripts or styles over plain HTTP
Your HTTPS page pulls a script or stylesheet from an http:// address, which anyone on the network can replace.
Guides
Free check
Does your site have PL-027?
Type your site’s address. The free headers check loads your public home page once, like any visitor, and grades HTTPS, the certificate, security headers, cookie flags and mixed content. No sign-up, and the result isn’t stored.
Last reviewed 10 Nov 2026. Finding IDs are stable: link to them freely. Spotted a mistake? Tell us.