How to build secure websites and APIs? | Part I — Rise of the Internet
When you build a website or an API, the first security concern is that it should be https. If it’s only http then user can’t really trust your website because anything that user sends to server can be read by anyone out there.
In this multi part series, I’ll explain why internet is insecure, how https makes it secure and how you can build your website or API over https.
Let’s dive in.
Most of the internet is not secure. The underlying network cannot be relied at all. Internet is a best effort service. It doesn’t guarantee delivery of data, or ordering of data. You can’t trust who sent you data. Anyone (with enough technical setup) can read any data sent over the internet.
Despite all these issues in internet networks, we are constantly able to experience highly secure, highly available connections over internet. How is that achieved? In this series, I’ll cover the security part of that question.
I’ll go through concepts and building blocks first, and at the end I’ll put all of them together to answer our original question: How to make secure websites and API?
Network layers
Internet is made of multiple layers. Physical layer, Network layer, Transport layer and Application layer. Each one is built on top of previous one.
Physical layer
Physical layer is where actual data transmission happens between end devices, routers and modems.
Network layer
Network layer is where source and destination devices exchange packets. Network layer pass packet to Physical layer, and physical layer divides that packets into smaller chunks and tries to deliver it to destination address. The Internet Protocol (IP) may or may not deliver packets to destination. Packets may be out of order when delivered, and anyone in between can read the packet data.
In Internet protocol, each device gets an IP address. That’s similar to an address of a physical building. IP protocol allows delivery of packets from source IP address to destination IP address. It’s like sending physical mail from one building to another building.
Transport layer
But a source device (like computer) can have multiple applications running in it and each one wants to send/receive data to/from different applications on destination device. That’s where Transportation layer comes to help us. Each device has N number of ports, and these ports are used to segregate packets coming to a device’s IP address. Let’s say your computer’s IP address is 192.168.0.1 then every application on your computer have same IP address. To segregate data, the packet must provide a destination port number (e.g. port 443 ). It’s like writing an apartment number when sending a postal mail. The Transportation layer handles this communication between source device port to destination device port.
TCP is a transportation layer algorithm which provides reliable, in-order delivery of packets between source and destination ports. UDP on the other hand don’t provide any guarantees.
Application layer
Finally the Application layer uses Transportation layer to build something meaningful out of that communication channel. HTTP is an application layer protocol that powers most of the websites. Browsers uses HTTP protocol to communicate with Servers and APIs.
Client Server communication
Most of the Web works in client-server architecture. Whenever you visit a website on your browser, the browser works as a client on your behalf. It requests webpages, resources from server and displays it to you. The servers are always ready to serve any requests coming from client.
The server is an application running on a machine, and any client communicate with application over an application protocol. Browsers communicate via HTTP protocol. A Http server is an application which accepts requests coming to port number 80 .
When you open a new tab in the browser, it asks for a port number with Operating System. OS assigns a port number (let’s say port 553) When you search for Google.com in that tab, the browser first find Google.com’s IP address by making a DNS query. If the IP address is already cached in system then that query is not needed. Once your browser gets an IP address, it then initiates a TCP connection between your machine’s port 553 and Google server’s port 80 (that’s the port number for an http server). After the connection is established, browser makes HTTP requests to server, and server returns an HTTP response. In order for browser to communicate with server, both of them need to speak the same language and that language is: none other than HTTP protocol.
The scary part
Lisa: You won’t believe what happened to me yesterday. I got a mail from IRS saying that they are waiving my taxes for this year. I just need to send them my social security details.
Tom: Great news! But how do you know it’s from IRS?
Lisa: I saw “From: IRS office” on mail.
Tom: Lisa, you can’t trust the “From: “ on the mail. Anyone can write “From: IRS office“ on the mail and send it you.
How does your browser know that it’s really talking to Google server? Well, we all know the IP address of Google.com, so if the packet is coming from that IP address then it must be Google’s server, right? The answer is No. Your device can’t really trust the From: IP address of packets that it receive.
Then how can it trust these packets coming from Google.com? Stay tuned to find it out.
Thank you for reading until the end.
Before you go:
- Please consider clapping (👏) on this article.
- Follow me on LinkedIn and Twitter for more ideas and resources like this.
See you next time!
