Jan Mikoláš
Glossary
HTTPS and TLS
HTTPS protects transport between a client and server from eavesdropping and undetected modification. It cannot determine whether a signed-in user is allowed to change an order.
Short definition
HTTP over a secure connection, not independent application authorization.
HTTPS is not a replacement for HTTP but HTTP used within a connection protected by TLS, or Transport Layer Security. Before sending a web request, the client and server agree on security parameters. The server presents a certificate for its domain, and the client verifies its trustworthiness, validity and match with the name it is connecting to.
Once TLS has been established successfully, data between the client and the specific connection endpoint is encrypted and protected against undetected modification. For an ordinary website, that endpoint is a reverse proxy or web server. If the infrastructure terminates TLS there, the connection between the proxy and backend is a separate segment that must be designed according to network trust and data sensitivity.
What it is used for
Every web request, sign-in and API integration
TLS protects the transport layer used by the web, APIs and automated communication.
- web pages, sign-in, administration interfaces and session cookies
- API tokens, authorization headers and sensitive requests from client applications
- webhooks, carrier and marketplace integrations, and payment communication
- loading JavaScript, styles, images and fonts without mixed content
- the secure context required for web features that browsers do not make available outside HTTPS
Practical example
An API behind a reverse proxy with a renewed certificate
A marketplace client calls an HTTPS API endpoint. The reverse proxy presents a certificate for api.example.cz, the TLS connection is verified and the proxy forwards the request to an internal application. The backend verifies the webhook HMAC signature or API token independently of the encrypted connection.
The configuration below shows only the principle: redirect HTTP to HTTPS and send HSTS only from an HTTPS response. The max-age value, supported protocol list and certificate management method must be selected and tested for the infrastructure rather than copied without context.
server {
listen 80;
server_name api.example.cz;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name api.example.cz;
add_header Strict-Transport-Security "max-age=31536000" always;
# certifikát a bezpečné TLS nastavení patří sem
}How it works
First a secure channel, then the HTTP request
The handshake is a cryptographic protocol; for application development, the important point is to understand which guarantees it provides and where they end.
- The client requests an HTTPS domain A browser or API client connects to the domain and offers supported TLS versions and algorithms.
- The server proves its identity The server sends a certificate and cryptographically proves possession of the corresponding private key. The client checks the trust chain, validity period and domain name.
- Key agreement Both sides derive shared keys for the specific connection. Subsequent transport uses efficient symmetric encryption and integrity checks.
- HTTP over TLS Only now do the URL, headers, cookies and request body travel through the protected channel to the server or reverse proxy.
- Application checks Even over HTTPS, the backend verifies the input, session or token, and user permissions. TLS does not perform this step.
Main parts and concepts
The certificate, encryption and lifecycle are different things.
Connection security depends on correct server configuration, the client and operational discipline.
Certificate and trusted authority
A certificate binds a public key to a domain name. The client verifies it through a trusted chain; merely possessing a certificate file is not proof that it matches the requested domain.
Encryption, integrity and server authentication
TLS aims to prevent data from being read or secretly modified in transit and usually authenticates the web server to the client. It does not automatically provide mutual client authentication; that requires mTLS or an application mechanism.
TLS termination
TLS can terminate at a CDN, load balancer or nginx. The next hop to the backend is not “automatically HTTPS”; the team needs to know who has network access and whether the hop is encrypted again.
HSTS and redirects
An HTTP redirect sends the user to HTTPS. HSTS tells the browser to use HTTPS directly on future visits to the domain; it should be introduced only after every subdomain and certificate has been carefully verified.
Mixed content
An HTTPS page must not load active resources over HTTP without careful consideration. An unencrypted script could bypass protection for the entire page even if the document itself was delivered over HTTPS.
Benefits and limitations
An essential layer that does not address every security concern.
Benefits
- confidentiality and integrity protection for data in transit
- verification of server identity for a trusted domain
- protection of sign-in, cookies, API tokens and content from ordinary network eavesdropping
- a prerequisite for secure contexts and many modern web features
Limitations and common mistakes
- HTTPS does not eliminate XSS, SQL injection, broken authorization or server-side data leaks
- an expired or incorrectly deployed certificate makes the application inaccessible to clients
- TLS termination without understanding the internal hop can create an unprotected part of the path
- HSTS with includeSubDomains can break a subdomain that does not support HTTPS
- an unencrypted external resource creates mixed content or weakens the page
When it makes sense
For a public website or service communicating over an untrusted network.
HTTPS belongs on a website, administration interface, API, webhook endpoint and integration client call. This is not limited to passwords or payments: URLs, cookies, response content and tokens can all have security or commercial value. The same principle applies to internal paths unless they are confined to a clearly defined trusted network.
A “green HTTPS” indicator is not an audit of the entire application. The system owner must address automatic certificate renewal, expiration monitoring, secure server configuration, redirects and testing of critical paths. The application still needs to authenticate users and protect sensitive data at rest and during processing.
What to consider
A secure connection is an operational commitment, not a one-time setting.
Certificate configuration and lifecycle belong in a monitored deployment.
- enforce HTTPS and test redirects for both ordinary and sensitive paths
- automate certificate renewal and monitor expiration dates
- use a current, secure TLS configuration supported by application clients
- know the exact point of TLS termination and how the next hop to the backend is secured
- remove mixed content and check the Secure attribute on sensitive cookies
- introduce HSTS only after verifying the domain scope and recovery procedure
Common questions
HTTPS, TLS and the boundaries of their protection
Are HTTPS and TLS the same thing?
HTTPS is the use of HTTP over TLS. TLS can also protect other application protocols, such as email or database connections.
Does the server or browser verify the certificate?
The server presents the certificate and proves possession of the corresponding private key. The browser or another client verifies its trust chain, validity and match with the domain.
Is HTTPS enough to secure an API?
No. HTTPS protects transport. The API still needs to verify a token or other authentication credentials, check permissions, validate input and work with data securely.
Should HSTS always include includeSubDomains?
Only when all current and future subdomains securely support HTTPS. Otherwise, the browser may block a legitimate service on a subdomain.
How I handle operational security
I combine secure transport with secure application boundaries.
When developing backends, I treat HTTPS, the public entry point, API integrations and server-side validation as connected parts of one operational design.