Slide 1 ----------- Slide 2 ----------- Part 1: Hey everyone! In our blogging app, users read posts and admins add new ones. APIs are like the messengers that carry data between the app and the server. Without them, nothing works! But they are open to abuse. Part 2: APIs are doors to your app. If they’re not locked properly, anyone can sneak in—stealing data or crashing your site. Scary, right? Part 3: Think about a hacker accessing unpublished blog posts or flooding your site with fake requests. Today, we’ll learn how to stop that! Part 4: Some think APIs are secure by default. Nope! Security isn’t automatic—you have to build it in. Part 5: Imagine an admin’s secret draft post leaking because we didn’t check who’s asking for it. That’s a data leak—sensitive info slipping out. Part 6: What if someone pretends to be the admin and deletes posts? That’s unauthorized access—huge trouble! Part 7: Ever heard of SQL injection? It’s like sneaking a command into a search bar to trick the server into spilling all posts. Part 8: A flood of fake requests could crash our blog, leaving readers frustrated. That’s a DDoS attack. Slide 3 ----------- Part 1: The mainstream approach is to authenticate users using your API. Authentication is like checking ID at the door. Only valid users—like our admin—get in. Part 2: We’ll use JSON Web Tokens (JWT). It’s a secure pass that proves you’re legit without sharing passwords. In our app, the admin logs in, gets a JWT, and uses it to manage posts. No token? No access! Part 3: We've covered this in the authentication lecture, but let's recap. The login route issues a new JWT token, which we can store in a cookie or in a local storage. Part 4: Then, each subsequent request reads the token. If the token is absent, the request is unauthenticated and fails. Part 5: We can also easily check the integrity of the token in case someone has tampered with its content. This could lead to unauthorised requests. Otherwise, we know who's knocking! Slide 4 ----------- Part 1: The other issue when dealing with APIs is the possibility of someone listening to the communication and stealing or manipulating sensitive data. This is also known as a man-in-the-middle attack. Using HTTPs severly limits this type of attack. Part 2: HTTPS is like sending your blog posts in a locked box. Without it, hackers can peek at everything! Part 3: You can use TLS certificates encrypt data between the client and server. It’s a must for our blogging app. The certificates are configured on the app level. Slide 5 ----------- Part 1: The other issues you may run into is someone either accidentally or malevolently flooding your API with millions of requests crashing your application. If so, you might have been targetted by DDoS attack. Part 2: Rate limiting caps how many requests someone can send. No more DDoS crashing our blog! Part 3: Throttling is a method used to control the number of requests that clients can make to our server, helping to ensure optimal performance. By implementing throttling, we establish a specific time interval during which a client can send a new request. For instance, we can set a rule that allows a client to create a new request only every five seconds. Any requests that arrive before this time period expires will be disregarded. This approach helps manage client activity and keeps our server running smoothly. Part 4: Let’s limit users to 100 requests every 15 minutes. Fair for readers, tough on attackers. Part 5: Using the express rate limit package, we can easily set the allowed number of requests per IP given the time frame. NextJS allows similar solutions. Slide 6 ----------- Part 1: Yet another problem that you can encounter is users sending malevolent or incorrect data to your API endpoint. Part 2: Validation ensures data—like a new blog post—fits what we expect. No funny business! You should validate data on client for better user experience, and then again on server for security reasons. Part 3: On top of validation, sanitisation strips out nasty stuff, like code meant to hack our database or start a cross-site scripting attack. Part 4: There are many libraries out there that will help you develop validation and sanitisation approaches. Part 5: Zod allows you to define the shape of your data, providing requirements on each property. Part 6: Then, we can use this schema to parse the incoming request assuring that data matches our expectations. Slide 7 ----------- Part 1: APIs need layers: authentication, encryption, limits, and validation. Our blog thrives with them! Part 2: Start secure—don’t bolt it on later. Test every endpoint like an admin or reader would. Part 3: Skipping HTTPS or weak tokens is like leaving your blog’s door unlocked. Don’t do it!