REST API Using HTTPS

Are RESTful APIs and HTTP APIs the same?

The short answer is no. As we saw in the introduction, for an API to be RESTful, it must adhere to the architectural constraints. HTTP API is any API that makes use of HTTP as its transfer protocol. For better security, it is recommended to HTTPS instead of HTTP.

What is HTTPS?

The “S” in HTTPS stands for secure, meaning that it’s a more secure version of HTTP.

What does HTTPS do?

HTTPS guarantees the following:

• Confidentiality: HTTPS ensures that users’ connection to the server is encrypted.
• Authenticity: The user is communicating with genuine websites and not phishing (spoofed) websites.
• Integrity: There is no tampering of the data or payload sent by the user.

A plain HTTP connection can be easily monitored, modified, and impersonated.

How HTTPS can be attacked

HTTPS can be attacked in the following ways:

• An attacker could take advantage of protocol or cipher weaknesses.
• A user’s device could be compromised using phishing or other techniques.
• A fake HTTPS certificate could pose as a genuine one.

All these are possible but require specialized skills and are expensive. In comparison to HTTPS, HTTP communication is easily intercepted and more prone to attack.

Making HTTPS secure

If we have HTTPS, does it mean it is fully secure? Let’s find out.

Any server which is ready to serve the internet will need to expose services or REST APIs. The server must have some certificate, preferably from a certificate authority. These will be SSL (secure sockets layer) or TSL (transport layer security) certificates on the internet.

We can view the certificate by clicking the padlock in the browser.

If we click on the padlock of an HTTPS site where we’ve purchased a certificate to inspect it and there is no reference to a SSL or TLS, what does this mean? Did we get the right certificate?

The answer is yes, we got the correct certificate, and it can be used with any protocol. TLS/SSL are protocols and the certificate is used for encryption purposes. There is a standard format of X.509 for the certificates. In cryptography, X.509 is a standard for defining the format of public key certificates. It contains a public key and an identity (a host name, an organization, or an individual). Typically, it is signed by a certificate authority, but it can also be self-assigned. This means someone holding that certificate can rely on the public key it contains to establish secure communications with another party or validate documents digitally signed by the corresponding private key.

If we have a valid X.509 certificate and implement it in our application server, are we fully secure in terms of HTTPS? The answer is no.

We’ll discuss additional controls required to make HTTPS fully secure in the next lesson.