HTTP

What is HTTP?

HTTP (HyperText Transfer Protocol) is an application protocol with which a client, such as a web browser or an application, sends requests to a server and receives responses in the form of HTML, JSON, XML or other data. It is the foundation of the web, but HTTP is also everywhere in industrial environments: in the web interface of a PLC, in the REST API of a Historian and in the link between an edge device and a cloud platform. Because plain HTTP has no encryption, its secure variant HTTPS is the norm for anything that leaves a protected zone.

In OT networks, HTTP is often used to access the web interfaces of devices such as PLCs, switches, drives and HMIs for configuration, diagnostics and logging.

🧠 How does HTTP work?

HTTP follows a simple request-response model:

1. A client (browser, script or application) opens a connection to a web server, by default on port 80.
2. The client sends a request containing a method, a path (for example /api/tags), headers and optionally a body.
3. The server returns a response with a status code, headers and the requested content.
4. HTTP/1.1 and HTTP/2 use TCP as the transport protocol over IP; HTTP/3 uses QUIC, which runs over UDP.

According to its specification, HTTP is a stateless protocol: each request can be understood on its own, independent of earlier requests. Login sessions are therefore tracked with cookies or tokens, which makes them vulnerable to session hijacking when traffic is not encrypted. In the OSI model, HTTP belongs to layer 7, the application layer.

Which methods and status codes does HTTP have?

RFC 9110 (June 2022) defines eight standard methods. In the REST APIs of industrial systems, GET, POST, PUT and DELETE are the most common, supplemented by PATCH from RFC 5789 for partial updates:

Status codes fall into five classes: 1xx (informational), 2xx (successful, such as 200 OK), 3xx (redirection, for example from HTTP to HTTPS), 4xx (client error, such as 401 Unauthorized or 404 Not Found) and 5xx (server error, such as 503 Service Unavailable).

🔄 Which versions of HTTP exist?

HTTP was developed by Tim Berners-Lee at CERN in 1989–1991 and has since been developed further by the IETF. In 2022 the whole family was re-specified: RFC 9110 describes the semantics shared by all versions, while RFC 9112, 9113 and 9114 describe the individual versions.

In practice, embedded web servers in field devices usually support HTTP/1.1 only. HTTP/2 and HTTP/3 are mainly found in cloud platforms and modern IT applications.

🏭 Where is HTTP used in industrial networks?

• Web configuration of network components - routers, firewalls and switches nearly always have a web interface.
• Diagnostics and maintenance of controllers - web interfaces on PLCs and IO modules show status and diagnostic buffers and allow firmware updates.
• REST API integrations - links between SCADA, MES, historians and other data sources increasingly use JSON over HTTP.
• Embedded web servers - devices show real-time status and simple visualisations without separate software.
• Edge and IIoT - tools such as Node-RED and Grafana work with HTTP endpoints, and process data is often pushed to external systems over HTTP client connections.
• OPC UA over HTTPS - besides its binary TCP protocol, OPC UA also defines an HTTPS mapping (opc.https) with binary, JSON or XML encoding, useful where firewalls only allow web traffic.

Here HTTP competes with MQTT. HTTP suits request-response traffic and occasional queries; MQTT is more efficient for continuously publishing many small measurements.

🔐 Why is unencrypted HTTP risky in OT?

With plain HTTP, everything crosses the network as readable text. Anyone with access to the network segment, for example through a compromised laptop or a mirror port on a switch, can capture the traffic with a tool such as Wireshark.

• Cleartext passwords - with HTTP Basic authentication (RFC 7617), the username and password are only Base64-encoded. That is encoding, not encryption: it can be reversed instantly.
• Man-In-The-Middle - an attacker can alter requests and responses in transit, for example a setpoint or a firmware file.
• Session hijacking - unencrypted session cookies can be stolen and reused.
• Vulnerable embedded web servers - many CVEs in industrial devices sit in the web interface: authentication bypass, buffer overflows or cross-site scripting.
• Default passwords - web interfaces reachable with factory settings are a well-known entry point for attackers.

How do HTTP and HTTPS differ?

🔧 How do you reduce HTTP risks in practice?

A practical approach for an existing installation:

1. Take inventory - scan which devices have ports 80, 8080 and 443 open and record this in your asset inventory.
2. Disable HTTP where possible - many modern PLCs, such as the Siemens S7-1500, can be configured to allow access via HTTPS only. Switch the web server off entirely if nobody uses it.
3. Replace self-signed certificates - use certificates from your own PKI and arrange renewal through certificate management.
4. Segment - restrict web access to a management zone with network segmentation, firewalls and ACLs; route external access through a jump server or remote maintenance solution with MFA.
5. Use a reverse proxy - for devices that only speak HTTP, a proxy in the DMZ or management zone can protect the user-facing connection with HTTPS.
6. Apply roles - use RBAC on web interfaces and change default passwords.
7. Monitor - send access logs via Syslog to a SIEM and let an IDS flag unencrypted login attempts.

In terms of standards, this aligns with IEC 62443-4-2, which sets requirements for communication integrity (CR 3.1) and confidentiality (CR 4.1), and with the Cyber Resilience Act, which applies in full from 11 December 2027 and expects data in transit to be protected with state-of-the-art encryption. Disabling unused web services is one of the first steps of hardening.

❓ Frequently asked questions

Which port does HTTP use?

HTTP uses TCP port 80 by default, and HTTPS uses port 443. Many industrial devices and applications also use alternative ports such as 8080 or 8443, and the port is usually configurable. A network scan should therefore look beyond port 80 alone.

Is HTTP secure enough inside an isolated OT network?

HTTP inside an isolated OT network is less risky than over the internet, but passwords and commands remain readable to anyone who can eavesdrop on the segment. An infected maintenance laptop or an insider is enough. HTTP is therefore acceptable at most in a small, well-segmented zone, and only when HTTPS is technically not possible.

What is the difference between HTTP and a REST API?

HTTP is the protocol that carries requests and responses. A REST API is a design style for interfaces that uses HTTP methods such as GET, POST, PUT and DELETE to read and change resources. Almost all REST APIs in MES, historian and cloud platforms run over HTTP or HTTPS.

Why is HTTP Basic authentication insecure?

HTTP Basic authentication sends the username and password with every request, only encoded with Base64. Base64 is not encryption and anyone can convert it straight back to the original password. Basic authentication is therefore only acceptable in combination with HTTPS.

Can I simply disable HTTP on a PLC?

You can disable HTTP on a PLC when nobody needs the web interface or when the device supports HTTPS. First check whether SCADA, an HMI or a script uses the web server, for example for user-defined web pages or data exchange. Test the change in a maintenance window and record it in your change management process.

Does HTTP always use TCP?

HTTP/1.1 and HTTP/2 use TCP, but HTTP/3 runs over QUIC, a protocol on top of UDP with built-in TLS 1.3 encryption. HTTP/3 hardly plays a role in OT environments yet, because embedded web servers in devices usually use HTTP/1.1.

📌 In summary

HTTP is the request-response protocol behind web interfaces and REST APIs, which makes it ubiquitous in OT environments, but without encryption passwords and commands are readable to anyone on the network. Use HTTPS wherever possible, disable unused web servers and confine any remaining HTTP traffic to a well-protected zone, as part of your overall security approach.