Background

In the past, I used to share my newly acquired knowledge through blogs. However, with the emergence of AI (Specifically LLM models), things have changed. Nowadays, everyone is asking AI questions, making traditional internet searches seem less valuable. Despite this shift, I still want to continue sharing through blogs because it allows me to practice my English writing and organize my thoughts in a structured way. However, given the rise of AI, I also plan to adapt my blog writing.

These days, it's fortunate to learn alongside AI—you can ask any question if you’re struggling with a specific topic. The key skill, though, is validating the answers that AI provides to ensure they’re correct and make sense. I believe this skill will become even more important as we live in the AI era, which is why I want to write this blog post with the help of AI.

I hope you enjoy this post, even though much of the content may be generated by AI. I still aim to share my perspective, and I hope this mindset is helpful to you.

I struggled with web security topics because I had many unanswered questions before. However, thanks to AI, I now have the opportunity to clarify everything; that's why I chose this topic as my first blog, which cooperates with AI, and  I will show you how to engage with AI back and forth to learn a specific topic.

Definitions

The following definitions are generated via AI; if you are familiar with them, you can skip this section.

SOP - Same-Origin Policy

The Same-Origin Policy (SOP) is a browser security mechanism that restricts web pages from accessing data from a different origin (protocol, domain, or port).

• Purpose: Prevents cross-site data theft and protects user sessions.
• Example: A script on https://example.comcannot read cookies from https://attacker.com.

CSRF - Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack that tricks a logged-in user into performing an unwanted action on a trusted website.

• How it works: The attack exploits the browser’s automatic cookie handling to send unauthorized requests.
• Example: A victim logs into bank.com, then visits attacker.com, which automatically submits a money transfer request to bank.com using the victim's session.
• Prevention: Use CSRF tokens, SameSite=Strict cookies, and re-authentication for sensitive actions.

CORS - Cross-Origin Resource Sharing

Cross-Origin Resource Sharing (CORS) is a security feature that allows controlled access to resources from different origins by defining which external sites can make requests.

• Why it's needed: SOP blocks all cross-origin requests by default, but CORS allows specific trusted domains to access an API.
• Example: If api.example.com wants to allow requests from frontend.com, the server must set: Access-Control-Allow-Origin: https://frontend.com
• Security risk: Misconfiguring CORS (Access-Control-Allow-Origin: *) can bypass CSRF protection, allowing attackers to send requests using a victim’s session.

Discussion with AI

In the past, I was familiar with the terms listed above individually, but I had questions about why we need to use all these concepts to design website security. One day, while logging into a Django website I was developing, I noticed I received both a sessionID and a csrftoken. The sessionID was marked as HttpOnly, while the csrftoken was not. This sparked my curiosity about why they had different attributes in the browser, so I decided to investigate further.

I opened the ChatGPT and asked the following question:

Q: I used Django to implement the login functionality. After logging in, I received two cookies: csrftoken and sessionid, and I’m curious about the difference between these cookies.

Ans: Django uses sessionid to keep track of logged-in users, and this ID is stored in a cookie on the user's browser. The session ID maps to session data stored on the server (e.g., in a database, cache, or file system). When the user makes subsequent requests, their browser sends the sessionid cookie, and Django reads this cookie, retrieves the session data, and associates it with the request.

The csrftoken is a Cross-Site Request Forgery (CSRF) token used by Django to prevent CSRF attacks. This token is stored in a cookie (csrftoken ) and embedded as a hidden field in the form. When the form is submitted, Django checks if the CSRF token included in the form matches the token stored in the user's cookie. Since browsers automatically include cookies in requests, an attacker could trick a logged-in user into making an unwanted request (e.g., submitting a form). The CSRF token ensures that only forms generated by Django are accepted.

Q: I noticed that the sessionid is HttpOnly, but the csrftoken is not. Why is that?

Ans: In Django, the sessionid cookie is marked as HttpOnly to enhance security. This attribute prevents client-side scripts from accessing the cookie, helping mitigate risks associated with cross-site scripting (XSS) attacks. By making the sessionid cookie HttpOnly, it cannot be accessed via JavaScript, which is why this tag helps prevent XSS risks.

Q: Can I use JavaScript to retrieve the csrftoken and inject it into a hidden form input? If so, that means a hacker could potentially do the same thing, right? Does this mean the CSRF token is ineffective?

Ans: Yes! You can use JavaScript to retrieve the CSRF token from the cookie and inject it into the hidden form input field dynamically, and due to the  CSRF token is stored in a cookie, but only for the same site, that's important, only for the same site, that's why we must set the SameSite=LAX at least within the Django. By doing that, JavaScript running on another origin cannot access the CSRF token due to browser security policies (Same-Origin Policy).

Q: If I configure the wrong settings, whether through Nginx or Django, to allow requests from different origins using Access-Control-Allow-Origin: *, and I don’t set the SameSite attribute on the CSRF token, could this configuration render the CSRF protection ineffective?

Ans: Yes, misconfiguring CORS (Access-Control-Allow-Origin: *) and not setting the SameSite attribute properly can make CSRF protection ineffective. Let’s break it down. Under this scenario, any origin (including attacker.com) can make requests to your API without restrictions. When a victim visits attacker.com, their sessionid and csrftokenare automatically included in cross-origin requests. Now, How an Attacker Exploits This

1. Victim logs into bank.com (legitimate site)
2. Victim visits attacker.com
3. The attacker executes a fetch() request to bank.com
4. Because of Access-Control-Allow-Origin: *, the request is allowed.
5. Because cookies are included (no SameSite restriction), the bank processes the request.
6. Attack Succeeds!

Finally, after asking a few questions, I now have a clear understanding of basic web security concepts like CSRF, SOP, and CORS. I now deeply appreciate the great advantage of today’s era, where asking AI questions helps resolve confusion.

Takeaways

In the final section, I’ll provide a quick summary of today’s topic, with the assistance of AI, of course. Hope you enjoy it.

Summary

✅ SOP blocks cross-origin requests by default.
✅ CORS allows specific cross-origin access (if configured correctly).
✅ CSRF protections prevent attackers from hijacking authenticated actions.