From 981bdfedbd1f8bd5d1b70bd0a6d212171fedea58 Mon Sep 17 00:00:00 2001
From: VietAnh <zackhoang2004@gmail.com>
Date: Thu, 17 Sep 2026 21:22:20 -0700
Subject: [PATCH 01/20] Add Advanced Topics lesson

---
 nodeJS/final_project/advanced_topics.md | 96 +++++++++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 nodeJS/final_project/advanced_topics.md

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
new file mode 100644
index 00000000000..a280818bde8
--- /dev/null
+++ b/nodeJS/final_project/advanced_topics.md
@@ -0,0 +1,96 @@
+### Introduction
+
+As you work on more sophisticated web applications, there are certain security guidelines to keep in mind as you go. In this lesson, we'll briefly talk about them and how you can incorporate that into your Express application.
+
+### Lesson overview
+
+This section contains a general overview of topics that you will learn in this lesson.
+
+- Content Security Policy.
+- Logging.
+- Cross Site Request Forgery.
+- Internationalisation.
+- Cross-Origin Resource Sharing.
+- Rate limiting.
+
+### Content Security Policy
+
+Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on your it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it prevents a few common vulnerabilities:
+
+- **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScripts into your app and target your clients.
+- **Clickjacking**: attackers could also embed certain HTML elements (such as `<iframe>` to overlay your app UI elements and trick users to click on those element to perform something destructive.)
+
+### Logging
+
+Imagine a client is using your to-do application to manage their tasks. For some reasons, they keep facing a `500 Internal Server Error` response and complaint about it. You opened up your app's logs and...it's empty? Oh no, where in your app could that request be failing?!
+
+Logging can help you with that: identifying what your app is doing at any given moment and displaying somer errors internally that will be helpful for debugging and/or providing some useful data analytics.
+
+But you shouldn't log everything! Too much logging can really take a hit on your app's resources. You also do not want to expose your users' credentials in your logs! What if an attacker gain access to your machine?
+
+Understand what needs to be logged. How you do tt could be as simple as a few `console.log()`s in certain routes or you could introduce an entire library like [pino](https://github.com/pinojs/pino) and let it do the heavy lifting for you.
+
+### Cross Site Request Forgery
+
+Another very common exploit in the World Wide Web. Imagine you encountered a strange but very innocent looking website called `cutekittens.com`...until you inspect its HTML that looks like this.
+
+```html
+<form action="https://my-bank.example.org/transfer" method="POST">
+  <input type="hidden" name="recipient" value="attacker" />
+  <input type="hidden" name="amount" value="1000" />
+</form>
+```
+
+"Wait I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? Cross Site Request Forgery (CSRF) attacks are just that: being tricked to perform a state-changing request to a certain target site from a mallicious site.
+
+So what could you do about it? One of the most common method is to use CSRF token. Everytime you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or a HTTP request header). Then, in your app, carry out the request if and only if the token is valid.
+
+### Internationalisation
+
+Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalisation (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process adapting your applications to different populations/languages.
+
+One approach to do this is detecting taking a look at your user's [Accept Language header's](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) value. Then, from a markup file (like json or yaml), serve content that matches with what your client prefers. Sometimes you might have over a dozen of translated content to keep track of. In that case, something like [i18n-js](https://github.com/fnando/i18n-js) can help.
+
+### Cross-Origin Resource Sharing
+
+We touched upon this concept briefly in the blog API project, but let's do a more formal explanation. Cross-Origin Resource Sharing (CORS) is a mechanism that allows you to access resource from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
+
+- `https://www.my-blog-app.com`
+- `https://www.my-blog-app-api.com`
+
+Normally, browsers will restrict cross-origin HTTP requests due to security concerns, like CSFR attacks, like we mentioned above. If we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as part of its accepted origin that it will deliver its responses to.
+
+Depending on what kind of method you use in your request, A pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This will often involve sending some kind of unique custom token to the server to verify. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) does not trigger a pre-flight request. Nonetheless, the request's origin must still be validate by the `Access-Control-Allow-Origin` header.
+
+### Rate-limiting
+
+Just like how your city has speed limit signs, [rate-limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting/) is a technique that tracks users' number of requests and putting a limit on how many times they could access a resource and/or how many requests a user is limited to per day. This is especially helpful when your API is starting to grow and protecting yourself from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
+
+This is commonly employed on sensitive end-points, like ones involving authentication. You might faced a similar problem where after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again for another half an hour so. This is rate-limiting coming into play because we want to protect users from brute-force log in attacks. Rate-limiting can involve tracking both a user's IP address and their username and checking how many requests has been made from them before our application stop or slow them down before any more requests are made.
+
+### Conclusion
+
+That was quite a lot that we covered. You don't have to apply all of these practices in your upcoming final project. That being said, hopefully by being aware of these concepts, you will be able to evaluate and design more reliable systems.
+
+### Assignment
+
+<div class="lesson-content__panel" markdown="1">
+
+1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
+1. MDN consists of many useful guides that will go more in depth with practical examples that you could learn from, so check those out as well.
+
+    - [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
+    - [Cross-Origin Resources Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
+    - [Cross Site Request Forgery](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF)
+
+</div>
+
+### Knowledge check
+
+The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
+
+- [What does Content Security Policy protect your app from?](#content-security-policy)
+- [When logging, what kind information should not appear?](#logging)
+- [What is Cross Site Request Forgery?](#cross-site-request-forgery)
+- [How does Cross-Origin Resources Sharing work?](#cross-origin-resource-sharing)
+- [Why is rate-limiting needed on sensitive routes?](#rate-limiting)

From b389234b39ef01d78d6ffe0dfe5f70680a52bd6e Mon Sep 17 00:00:00 2001
From: VietAnh <zackhoang2004@gmail.com>
Date: Thu, 17 Sep 2026 21:29:28 -0700
Subject: [PATCH 02/20] Fix various typos and phrasing

---
 nodeJS/final_project/advanced_topics.md | 48 ++++++++++++-------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index a280818bde8..724100907b0 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -8,29 +8,29 @@ This section contains a general overview of topics that you will learn in this l
 
 - Content Security Policy.
 - Logging.
-- Cross Site Request Forgery.
+- Cross-Site Request Forgery.
 - Internationalisation.
 - Cross-Origin Resource Sharing.
-- Rate limiting.
+- Rate-limiting.
 
 ### Content Security Policy
 
-Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on your it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it prevents a few common vulnerabilities:
+Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it prevents a few common vulnerabilities:
 
-- **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScripts into your app and target your clients.
-- **Clickjacking**: attackers could also embed certain HTML elements (such as `<iframe>` to overlay your app UI elements and trick users to click on those element to perform something destructive.)
+- **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScript into your app and target your clients.
+- **Clickjacking**: attackers could also embed certain HTML elements (such as `<iframe>` to overlay your app UI elements and trick users to click on those elements to perform something destructive.)
 
 ### Logging
 
-Imagine a client is using your to-do application to manage their tasks. For some reasons, they keep facing a `500 Internal Server Error` response and complaint about it. You opened up your app's logs and...it's empty? Oh no, where in your app could that request be failing?!
+Imagine a client is using your to-do application to manage their tasks. For some reason, they keep facing a `500 Internal Server Error` response and complain about it. You opened up your app's logs and...it's empty? Oh no, where in your app could that request be failing?!
 
-Logging can help you with that: identifying what your app is doing at any given moment and displaying somer errors internally that will be helpful for debugging and/or providing some useful data analytics.
+Logging can help you with that: identifying what your app is doing at any given moment and displaying some errors internally that will be helpful for debugging and/or providing some useful data analytics.
 
-But you shouldn't log everything! Too much logging can really take a hit on your app's resources. You also do not want to expose your users' credentials in your logs! What if an attacker gain access to your machine?
+But you shouldn't log everything! Too much logging can really take a hit on your app's resources. You also do not want to expose your users' credentials in your logs! What if an attacker gains access to your machine?
 
-Understand what needs to be logged. How you do tt could be as simple as a few `console.log()`s in certain routes or you could introduce an entire library like [pino](https://github.com/pinojs/pino) and let it do the heavy lifting for you.
+Understand what needs to be logged. How you do it could be as simple as a few `console.log()`s in certain routes or you could introduce an entire library like [pino](https://github.com/pinojs/pino) and let it do the heavy lifting for you.
 
-### Cross Site Request Forgery
+### Cross-Site Request Forgery
 
 Another very common exploit in the World Wide Web. Imagine you encountered a strange but very innocent looking website called `cutekittens.com`...until you inspect its HTML that looks like this.
 
@@ -41,32 +41,32 @@ Another very common exploit in the World Wide Web. Imagine you encountered a str
 </form>
 ```
 
-"Wait I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? Cross Site Request Forgery (CSRF) attacks are just that: being tricked to perform a state-changing request to a certain target site from a mallicious site.
+"Wait, I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? Cross-Site Request Forgery (CSRF) attacks are just that: tricking a user into performing a state-changing request to a certain target site from a malicious site.
 
-So what could you do about it? One of the most common method is to use CSRF token. Everytime you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or a HTTP request header). Then, in your app, carry out the request if and only if the token is valid.
+So what could you do about it? One of the most common methods is to use a CSRF token. Every time you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or an HTTP request header). Then, in your app, carry out the request if and only if the token is valid.
 
 ### Internationalisation
 
-Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalisation (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process adapting your applications to different populations/languages.
+Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalisation (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages.
 
-One approach to do this is detecting taking a look at your user's [Accept Language header's](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) value. Then, from a markup file (like json or yaml), serve content that matches with what your client prefers. Sometimes you might have over a dozen of translated content to keep track of. In that case, something like [i18n-js](https://github.com/fnando/i18n-js) can help.
+One approach to do this is taking a look at your user's [Accept-Language header's](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) value. Then, from a data file (like JSON or YAML), serve content that matches what your client prefers. Sometimes you might have over a dozen translated strings to keep track of. In that case, something like [i18n-js](https://github.com/fnando/i18n-js) can help.
 
 ### Cross-Origin Resource Sharing
 
-We touched upon this concept briefly in the blog API project, but let's do a more formal explanation. Cross-Origin Resource Sharing (CORS) is a mechanism that allows you to access resource from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
+We touched upon this concept briefly in the blog API project, but let's do a more formal explanation. Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to grant access to its resources from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
 
 - `https://www.my-blog-app.com`
 - `https://www.my-blog-app-api.com`
 
-Normally, browsers will restrict cross-origin HTTP requests due to security concerns, like CSFR attacks, like we mentioned above. If we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as part of its accepted origin that it will deliver its responses to.
+Normally, browsers will restrict cross-origin HTTP requests due to security concerns, such as CSRF attacks, which we mentioned above. If we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as one of its allowed origins.
 
-Depending on what kind of method you use in your request, A pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This will often involve sending some kind of unique custom token to the server to verify. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) does not trigger a pre-flight request. Nonetheless, the request's origin must still be validate by the `Access-Control-Allow-Origin` header.
+Depending on what kind of method you use in your request, a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) do not trigger a pre-flight request. Nonetheless, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
 
 ### Rate-limiting
 
-Just like how your city has speed limit signs, [rate-limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting/) is a technique that tracks users' number of requests and putting a limit on how many times they could access a resource and/or how many requests a user is limited to per day. This is especially helpful when your API is starting to grow and protecting yourself from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
+Just like how your city has speed limit signs, [rate-limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting/) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
 
-This is commonly employed on sensitive end-points, like ones involving authentication. You might faced a similar problem where after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again for another half an hour so. This is rate-limiting coming into play because we want to protect users from brute-force log in attacks. Rate-limiting can involve tracking both a user's IP address and their username and checking how many requests has been made from them before our application stop or slow them down before any more requests are made.
+This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate-limiting coming into play because we want to protect users from brute-force login attacks. Rate-limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
 
 ### Conclusion
 
@@ -80,8 +80,8 @@ That was quite a lot that we covered. You don't have to apply all of these pract
 1. MDN consists of many useful guides that will go more in depth with practical examples that you could learn from, so check those out as well.
 
     - [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
-    - [Cross-Origin Resources Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
-    - [Cross Site Request Forgery](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF)
+    - [Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
+    - [Cross-Site Request Forgery](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF)
 
 </div>
 
@@ -90,7 +90,7 @@ That was quite a lot that we covered. You don't have to apply all of these pract
 The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
 
 - [What does Content Security Policy protect your app from?](#content-security-policy)
-- [When logging, what kind information should not appear?](#logging)
-- [What is Cross Site Request Forgery?](#cross-site-request-forgery)
-- [How does Cross-Origin Resources Sharing work?](#cross-origin-resource-sharing)
+- [When logging, what kind of information should not appear?](#logging)
+- [What is Cross-Site Request Forgery?](#cross-site-request-forgery)
+- [How does Cross-Origin Resource Sharing work?](#cross-origin-resource-sharing)
 - [Why is rate-limiting needed on sensitive routes?](#rate-limiting)

From e614611fc47cb3f657ad14c7e288c768490292c1 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 15:57:44 -0700
Subject: [PATCH 03/20] Fix introduction framing

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 724100907b0..67d75bf2224 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -1,6 +1,6 @@
 ### Introduction
 
-As you work on more sophisticated web applications, there are certain security guidelines to keep in mind as you go. In this lesson, we'll briefly talk about them and how you can incorporate that into your Express application.
+As you work on more sophisticated web applications, there are some further concepts that might be good for you to be aware of, which we've left until now to avoid rabbit holes. In this lesson, we'll briefly talk about some of them along with possible ways to incorporate them into your Express applications.
 
 ### Lesson overview
 

From 6ee6553505022deb1be2246dbbccfb08aed3083b Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 15:58:35 -0700
Subject: [PATCH 04/20] Fix CSP paragraph

It was being too much "if you do this everything will be okay"

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 67d75bf2224..86983aa4697 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -15,7 +15,7 @@ This section contains a general overview of topics that you will learn in this l
 
 ### Content Security Policy
 
-Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it prevents a few common vulnerabilities:
+Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it can prevent a few common vulnerabilities:
 
 - **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScript into your app and target your clients.
 - **Clickjacking**: attackers could also embed certain HTML elements (such as `<iframe>` to overlay your app UI elements and trick users to click on those elements to perform something destructive.)

From 9ad84e1443dbfdd7bd0efde2ba27b81b7e5cb1b4 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 16:02:21 -0700
Subject: [PATCH 05/20] Add more details for Clickjacking

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 86983aa4697..eeb8ad87c83 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -18,7 +18,7 @@ This section contains a general overview of topics that you will learn in this l
 Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it can prevent a few common vulnerabilities:
 
 - **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScript into your app and target your clients.
-- **Clickjacking**: attackers could also embed certain HTML elements (such as `<iframe>` to overlay your app UI elements and trick users to click on those elements to perform something destructive.)
+- **Clickjacking**: Attackers could also embed certain HTML elements (such as an `<iframe>`), overlaying your UI and hiding what's really under it. A user clicks something, thinking it'll done one thing, but the real button underneath actually does something different instead, such as overlaying a fake "close" button over a "submit" button.
 
 ### Logging
 

From ced9ce6cd63e2db897c606a51ab06b8f32a0ba05 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 16:08:27 -0700
Subject: [PATCH 06/20] Fix "Internationalisation" -> "Internationalization"

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index eeb8ad87c83..33998e05e0e 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -45,7 +45,7 @@ Another very common exploit in the World Wide Web. Imagine you encountered a str
 
 So what could you do about it? One of the most common methods is to use a CSRF token. Every time you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or an HTTP request header). Then, in your app, carry out the request if and only if the token is valid.
 
-### Internationalisation
+### Internationalization
 
 Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalisation (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages.
 

From 9e908d0c32d2e33da82c5ef2c3488f49d230e5a6 Mon Sep 17 00:00:00 2001
From: VietAnh <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 17:21:21 -0700
Subject: [PATCH 07/20] Reframe serveral conceptual ideas

---
 nodeJS/final_project/advanced_topics.md | 46 ++++++++++++-------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 33998e05e0e..998e1dd953b 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -11,24 +11,20 @@ This section contains a general overview of topics that you will learn in this l
 - Cross-Site Request Forgery.
 - Internationalisation.
 - Cross-Origin Resource Sharing.
-- Rate-limiting.
+- Rate limiting.
 
 ### Content Security Policy
 
-Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. Content Security Policy (CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it can prevent a few common vulnerabilities:
+Depending on the app you are building, chances are you might want to limit what kind of resources are allowed on it. [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) is a feature that allows you to restrict what resources are loaded on your pages. This is important because it can prevent a few common vulnerabilities:
 
-- **Cross-site scripting (XSS)**: the most common reason why you would want to employ CSP. You do not want to allow attackers to freely inject JavaScript into your app and target your clients.
+- **Cross-site scripting (XSS)**: The most common reason why you would want to employ a CSP. By restricting how JavaScript could be loaded and/or injected into your app, you can protect your app and your clients.
 - **Clickjacking**: Attackers could also embed certain HTML elements (such as an `<iframe>`), overlaying your UI and hiding what's really under it. A user clicks something, thinking it'll done one thing, but the real button underneath actually does something different instead, such as overlaying a fake "close" button over a "submit" button.
 
 ### Logging
 
-Imagine a client is using your to-do application to manage their tasks. For some reason, they keep facing a `500 Internal Server Error` response and complain about it. You opened up your app's logs and...it's empty? Oh no, where in your app could that request be failing?!
+Logging information in your app can help you identify what your app is doing at any given moment and display some errors internally that will be helpful for debugging and/or providing some useful data analytics, such your app's traffic distribution, how long do users tend to stay on certain endpoints, etc. The main point about leaving a series of ongoing record is that you could look back and see what went wrong or right, like leaving an entry in your diary!
 
-Logging can help you with that: identifying what your app is doing at any given moment and displaying some errors internally that will be helpful for debugging and/or providing some useful data analytics.
-
-But you shouldn't log everything! Too much logging can really take a hit on your app's resources. You also do not want to expose your users' credentials in your logs! What if an attacker gains access to your machine?
-
-Understand what needs to be logged. How you do it could be as simple as a few `console.log()`s in certain routes or you could introduce an entire library like [pino](https://github.com/pinojs/pino) and let it do the heavy lifting for you.
+Logging could be as simple as a few `console.log()`s in certain routes or you could introduce an entire library like [pino](https://github.com/pinojs/pino) or [winston](https://github.com/winstonjs/winston) into your workflow. These libraries are often optimized for performance and can give you back a lot of detail that'll prove useful.
 
 ### Cross-Site Request Forgery
 
@@ -41,19 +37,28 @@ Another very common exploit in the World Wide Web. Imagine you encountered a str
 </form>
 ```
 
-"Wait, I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? Cross-Site Request Forgery (CSRF) attacks are just that: tricking a user into performing a state-changing request to a certain target site from a malicious site.
+Then, within that site, a small but very dangerous snippet of JavaScript is embedded and will be loaded if anyone clicked on it...
+
+```javascript
+const form = document.querySelector("form");
+form.submit();
+```
+
+Assuming you are still logged in and your banking app's cookies still persist, disaster has already been struck! "Wait, I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? [Cross-Site Request Forgery (CSRF) attacks](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) are just that: tricking a user into performing a state-changing request to a certain target site from a malicious site. In this case, a form was automatically submit the moment you landed on `cutekittnes.com` and a banking transaction was silently performed.
 
 So what could you do about it? One of the most common methods is to use a CSRF token. Every time you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or an HTTP request header). Then, in your app, carry out the request if and only if the token is valid.
 
 ### Internationalization
 
-Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalisation (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages.
+Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalization (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages. This could involve taking a look at a client's [Accept-Language header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) and serve the content in the language that they want to see.
 
-One approach to do this is taking a look at your user's [Accept-Language header's](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) value. Then, from a data file (like JSON or YAML), serve content that matches what your client prefers. Sometimes you might have over a dozen translated strings to keep track of. In that case, something like [i18n-js](https://github.com/fnando/i18n-js) can help.
+MDN documentations also accomodate a wide range of langauges! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
 
 ### Cross-Origin Resource Sharing
 
-We touched upon this concept briefly in the blog API project, but let's do a more formal explanation. Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to grant access to its resources from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
+Previously on the blog API project, when we want to share data across two different origins, we'll have to configure reverse proxies on our platform that we host our SPA. Recall that reverse proxies allow requests from our front end app to travel to our back end as if both apps were on the same origin (or first-party). When there is no reverse proxy in-between, that is when we will have to be concerned about Cross-Origin Resource Sharing.
+
+Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to grant access to its resources from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
 
 - `https://www.my-blog-app.com`
 - `https://www.my-blog-app-api.com`
@@ -62,26 +67,21 @@ Normally, browsers will restrict cross-origin HTTP requests due to security conc
 
 Depending on what kind of method you use in your request, a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) do not trigger a pre-flight request. Nonetheless, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
 
-### Rate-limiting
+### Rate limiting
 
-Just like how your city has speed limit signs, [rate-limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting/) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
+Just like how your city has speed limit signs, [rate limiting](<https://www.cloudflare.com/learning/bots/what-is-rate> limiting/) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
 
-This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate-limiting coming into play because we want to protect users from brute-force login attacks. Rate-limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
+This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate limiting coming into play because we want to protect users from brute-force login attacks. rate limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
 
 ### Conclusion
 
-That was quite a lot that we covered. You don't have to apply all of these practices in your upcoming final project. That being said, hopefully by being aware of these concepts, you will be able to evaluate and design more reliable systems.
+That was quite a lot that we covered. Hopefully by being aware of these concepts, you are now able to imagine what goes on under the hood of the software you are using in your everyday life.
 
 ### Assignment
 
 <div class="lesson-content__panel" markdown="1">
 
 1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
-1. MDN consists of many useful guides that will go more in depth with practical examples that you could learn from, so check those out as well.
-
-    - [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
-    - [Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
-    - [Cross-Site Request Forgery](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF)
 
 </div>
 
@@ -93,4 +93,4 @@ The following questions are an opportunity to reflect on key topics in this less
 - [When logging, what kind of information should not appear?](#logging)
 - [What is Cross-Site Request Forgery?](#cross-site-request-forgery)
 - [How does Cross-Origin Resource Sharing work?](#cross-origin-resource-sharing)
-- [Why is rate-limiting needed on sensitive routes?](#rate-limiting)
+- [Why is rate limiting needed on sensitive routes?](#rate limiting)

From d4d551c9856b20e59bfb2ac62948a7ae1399f25b Mon Sep 17 00:00:00 2001
From: VietAnh <zackhoang2004@gmail.com>
Date: Sat, 19 Sep 2026 17:23:35 -0700
Subject: [PATCH 08/20] Fix a few typos

---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 998e1dd953b..ce5f083e4f6 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -52,7 +52,7 @@ So what could you do about it? One of the most common methods is to use a CSRF t
 
 Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalization (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages. This could involve taking a look at a client's [Accept-Language header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) and serve the content in the language that they want to see.
 
-MDN documentations also accomodate a wide range of langauges! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
+MDN documentations also accommodate a wide range of languages! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
 
 ### Cross-Origin Resource Sharing
 

From e23d25d71134a97e714b0cc5ab4f140dc72e1e45 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Fri, 25 Sep 2026 13:48:28 -0700
Subject: [PATCH 09/20] Remove Knowledge Check Section
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Goran Jović <goran1010jovic@gmail.com>
---
 nodeJS/final_project/advanced_topics.md | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index ce5f083e4f6..c7af64138cb 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -84,13 +84,3 @@ That was quite a lot that we covered. Hopefully by being aware of these concepts
 1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
 
 </div>
-
-### Knowledge check
-
-The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
-
-- [What does Content Security Policy protect your app from?](#content-security-policy)
-- [When logging, what kind of information should not appear?](#logging)
-- [What is Cross-Site Request Forgery?](#cross-site-request-forgery)
-- [How does Cross-Origin Resource Sharing work?](#cross-origin-resource-sharing)
-- [Why is rate limiting needed on sensitive routes?](#rate limiting)

From a7e9eb59400d5d533ff1d7b1891c1bac3bbc0ee9 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Fri, 25 Sep 2026 14:05:14 -0700
Subject: [PATCH 10/20] Fix href

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index c7af64138cb..bd0208bc92c 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -69,7 +69,7 @@ Depending on what kind of method you use in your request, a pre-flight request (
 
 ### Rate limiting
 
-Just like how your city has speed limit signs, [rate limiting](<https://www.cloudflare.com/learning/bots/what-is-rate> limiting/) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
+Just like how your city has speed limit signs, [rate limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
 
 This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate limiting coming into play because we want to protect users from brute-force login attacks. rate limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
 

From d03b6a3d132b8a396644c1274f8b1e91959a9150 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Thu, 1 Oct 2026 10:03:25 -0700
Subject: [PATCH 11/20] Reword CORS protection capability
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Goran Jović <goran1010jovic@gmail.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index bd0208bc92c..a6c66f6750a 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -63,7 +63,7 @@ Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to gran
 - `https://www.my-blog-app.com`
 - `https://www.my-blog-app-api.com`
 
-Normally, browsers will restrict cross-origin HTTP requests due to security concerns, such as CSRF attacks, which we mentioned above. If we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as one of its allowed origins.
+Normally, browsers will restrict cross-origin HTTP requests due to security concerns - without that restriction, any site you visited could read your data from any other site you happened to be logged into. So if we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as one of its allowed origins.
 
 Depending on what kind of method you use in your request, a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) do not trigger a pre-flight request. Nonetheless, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
 

From 51fca424fcb39e58d75139875be04bc36e0854f1 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Thu, 1 Oct 2026 10:04:33 -0700
Subject: [PATCH 12/20] Reword when pre-flight requests gets sent
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Goran Jović <goran1010jovic@gmail.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index a6c66f6750a..ee69a88934f 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -65,7 +65,7 @@ Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to gran
 
 Normally, browsers will restrict cross-origin HTTP requests due to security concerns - without that restriction, any site you visited could read your data from any other site you happened to be logged into. So if we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as one of its allowed origins.
 
-Depending on what kind of method you use in your request, a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Pre-flight requests are necessary for methods (such as `POST`) that could alter the state of our application. Non-destructive requests (like `GET`) do not trigger a pre-flight request. Nonetheless, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
+Depending on whether or not a request is a [simple request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests), a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Either way, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
 
 ### Rate limiting
 

From 5301dd44df6ea0e9282313285e214b0aefcba43d Mon Sep 17 00:00:00 2001
From: VietAnh <zackhoang2004@gmail.com>
Date: Sat, 3 Oct 2026 20:34:30 -0700
Subject: [PATCH 13/20] Remove CORS section

---
 nodeJS/final_project/advanced_topics.md | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index ee69a88934f..8e598891f23 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -8,7 +8,6 @@ This section contains a general overview of topics that you will learn in this l
 
 - Content Security Policy.
 - Logging.
-- Cross-Site Request Forgery.
 - Internationalisation.
 - Cross-Origin Resource Sharing.
 - Rate limiting.
@@ -54,19 +53,6 @@ Eventually, you might want to adapt your app to a wider range of audiences aroun
 
 MDN documentations also accommodate a wide range of languages! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
 
-### Cross-Origin Resource Sharing
-
-Previously on the blog API project, when we want to share data across two different origins, we'll have to configure reverse proxies on our platform that we host our SPA. Recall that reverse proxies allow requests from our front end app to travel to our back end as if both apps were on the same origin (or first-party). When there is no reverse proxy in-between, that is when we will have to be concerned about Cross-Origin Resource Sharing.
-
-Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to grant access to its resources from different origins. Let's take the blog API project as an example. Suppose you have the following origins for both your front-end React app and your Express app:
-
-- `https://www.my-blog-app.com`
-- `https://www.my-blog-app-api.com`
-
-Normally, browsers will restrict cross-origin HTTP requests due to security concerns - without that restriction, any site you visited could read your data from any other site you happened to be logged into. So if we want to enable resource sharing across a different origin, we'll have to configure our API to accept `my-blog-app` as one of its allowed origins.
-
-Depending on whether or not a request is a [simple request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests), a pre-flight request (a request to verify before our request) might be made to determine if such request could be safely made. This is done automatically by the browser via an `OPTIONS` request, using headers like `Access-Control-Request-Method` and `Origin` to ask the server what's allowed. Either way, the request's origin must still be validated by the `Access-Control-Allow-Origin` header.
-
 ### Rate limiting
 
 Just like how your city has speed limit signs, [rate limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
@@ -84,3 +70,12 @@ That was quite a lot that we covered. Hopefully by being aware of these concepts
 1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
 
 </div>
+
+### Knowledge check
+
+The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
+
+- [What does Content Security Policy protect your app from?](#content-security-policy)
+- [When logging, what kind of information should not appear?](#logging)
+- [What is Cross-Site Request Forgery?](#cross-site-request-forgery)
+- [Why is rate limiting needed on sensitive routes?](#rate limiting)

From fb1b1e9b7a8ee17bd93a159f3f9e9fe99d19167c Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sun, 4 Oct 2026 11:58:19 -0700
Subject: [PATCH 14/20] Remove knowledge check section
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Goran Jović <goran1010jovic@gmail.com>
---
 nodeJS/final_project/advanced_topics.md | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 8e598891f23..8d06e7ca811 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -70,12 +70,3 @@ That was quite a lot that we covered. Hopefully by being aware of these concepts
 1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
 
 </div>
-
-### Knowledge check
-
-The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
-
-- [What does Content Security Policy protect your app from?](#content-security-policy)
-- [When logging, what kind of information should not appear?](#logging)
-- [What is Cross-Site Request Forgery?](#cross-site-request-forgery)
-- [Why is rate limiting needed on sensitive routes?](#rate limiting)

From fb3d4d913f850b0d65d3877850ad29d451a88eb6 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Mon, 26 Oct 2026 10:54:25 -0700
Subject: [PATCH 15/20] Re-add CSRF title

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index 8d06e7ca811..a0d34abd991 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -9,7 +9,7 @@ This section contains a general overview of topics that you will learn in this l
 - Content Security Policy.
 - Logging.
 - Internationalisation.
-- Cross-Origin Resource Sharing.
+- Cross-Site Request Forgery.
 - Rate limiting.
 
 ### Content Security Policy

From e4eba2d9935c46c8f117e1123e2cf68ec3ba5b6b Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Mon, 26 Oct 2026 10:55:51 -0700
Subject: [PATCH 16/20] Grammar fix

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index a0d34abd991..ce3e8568c0d 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -51,7 +51,7 @@ So what could you do about it? One of the most common methods is to use a CSRF t
 
 Eventually, you might want to adapt your app to a wider range of audiences around the world. [Internationalization (I18n)](https://learn.microsoft.com/en-us/globalization/methodology/software-internationalization) is a process of adapting your applications to different populations/languages. This could involve taking a look at a client's [Accept-Language header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) and serve the content in the language that they want to see.
 
-MDN documentations also accommodate a wide range of languages! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
+For example, MDN can accommodate a wide range of languages! For example, <https://developer.mozilla.org/fr/> will display all your pages in MDN in French! C'est pratique, non?
 
 ### Rate limiting
 

From 6dace8820a4aaf887ad62e57c825604d4158b31f Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Mon, 26 Oct 2026 10:57:36 -0700
Subject: [PATCH 17/20] Typo fix

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index ce3e8568c0d..d47fe353307 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -57,7 +57,7 @@ For example, MDN can accommodate a wide range of languages! For example, <https:
 
 Just like how your city has speed limit signs, [rate limiting](https://www.cloudflare.com/learning/bots/what-is-rate-limiting) is a technique that tracks a user's number of requests and puts a limit on how many times they can access a resource, such as how many requests they're allowed per day. This becomes especially important as your API grows, protecting you from [Denial of Service](https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/) attacks.
 
-This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate limiting coming into play because we want to protect users from brute-force login attacks. rate limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
+This is commonly employed on sensitive endpoints, like ones involving authentication. You might've faced a similar problem where, after a number of unsuccessful attempts of logging into an application, it will temporarily lock you out and remind you to try again after half an hour or so. This is rate limiting coming into play because we want to protect users from brute-force login attacks. Rate limiting can involve tracking both a user's IP address and their username and checking how many requests they have made before our application stops or slows them down before any more requests are made.
 
 ### Conclusion
 

From 6b90b0736c25243e929552c2d3b813f8e8cfdaf2 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Mon, 26 Oct 2026 10:58:03 -0700
Subject: [PATCH 18/20] Reword conclusion

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index d47fe353307..bcbe1ecf6df 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -61,7 +61,7 @@ This is commonly employed on sensitive endpoints, like ones involving authentica
 
 ### Conclusion
 
-That was quite a lot that we covered. Hopefully by being aware of these concepts, you are now able to imagine what goes on under the hood of the software you are using in your everyday life.
+We covered quite a lot. Hopefully by being aware of these concepts, you are now able to imagine what goes on under the hood of the software you are using in your everyday life.
 
 ### Assignment
 

From ad1ed02a511d62ee0d243d2338d80aa8a52e0499 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Mon, 26 Oct 2026 10:59:03 -0700
Subject: [PATCH 19/20] Change "will" to "can"

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index bcbe1ecf6df..c259da9e336 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -67,6 +67,6 @@ We covered quite a lot. Hopefully by being aware of these concepts, you are now
 
 <div class="lesson-content__panel" markdown="1">
 
-1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) will help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
+1. [ExpressJS' security best practices](https://expressjs.com/en/advanced/best-practice-security/) can help you well in securing your Express app. This guide also suggests a few libraries that could be helpful, should you want to tighten up your app's security without doing everything from scratch.
 
 </div>

From 390d7442ad13940590431357ed1f1517f875b3f2 Mon Sep 17 00:00:00 2001
From: Zack Hoang <zackhoang2004@gmail.com>
Date: Sat, 7 Nov 2026 17:18:39 -0700
Subject: [PATCH 20/20] Fix typo

Co-authored-by: mao-sz <122839503+mao-sz@users.noreply.github.com>
---
 nodeJS/final_project/advanced_topics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nodeJS/final_project/advanced_topics.md b/nodeJS/final_project/advanced_topics.md
index c259da9e336..b8aa55eaeba 100644
--- a/nodeJS/final_project/advanced_topics.md
+++ b/nodeJS/final_project/advanced_topics.md
@@ -43,7 +43,7 @@ const form = document.querySelector("form");
 form.submit();
 ```
 
-Assuming you are still logged in and your banking app's cookies still persist, disaster has already been struck! "Wait, I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? [Cross-Site Request Forgery (CSRF) attacks](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) are just that: tricking a user into performing a state-changing request to a certain target site from a malicious site. In this case, a form was automatically submit the moment you landed on `cutekittnes.com` and a banking transaction was silently performed.
+Assuming you are still logged in and your banking app's cookies still persist, disaster has already been struck! "Wait, I just want to see kittens! Why is my money gone?!" Yikes, you don't want that, right? [Cross-Site Request Forgery (CSRF) attacks](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) are just that: tricking a user into performing a state-changing request to a certain target site from a malicious site. In this case, a form was automatically submit the moment you landed on `cutekittens.com` and a banking transaction was silently performed.
 
 So what could you do about it? One of the most common methods is to use a CSRF token. Every time you prompt your user to perform some state-changing request in your application, check for a hidden, unpredictable key (this could be embedded inside a `<form>` or an HTTP request header). Then, in your app, carry out the request if and only if the token is valid.