diff --git a/headers_manipulation/README.md b/headers_manipulation/README.md
new file mode 100644
index 0000000..f6b56ca
--- /dev/null
+++ b/headers_manipulation/README.md
@@ -0,0 +1,26 @@
+# Headers manipulation 
+
+## How We Found It
+the page where this was, is a little bit hidden, to go to this page, you have to click on the copyright notice in the footer. this page has nothing weird but when we open the html of the page, there is a comment saying :
+```
+You must come from : "https://www.nsa.gov/".
+```
+and another comment saying : 
+```
+Let's use this browser : "ft_bornToSec". It will help you a lot.
+```
+so using curl, I changed the `Referer` and `User-Agent` headers with this command :
+```
+curl "http://10.12.248.155/?page=b7e44c7a40c5f80139f0a50f3650fb2bd8d00b0d24667c4c2ca32c88e13b758f" -H "Referer: https://www.nsa.gov/" -H "User-Agent: ft_bornToSec"
+```
+
+## Utility of It
+- Lets an attacker bypass access restrictions by faking headers like Referer or User-Agent.
+- Can expose hidden or restricted content (like flags) without proper authentication.
+- Shows over-reliance on easily spoofed client headers.
+
+## How Can We Patch It
+- Never trust client-controlled headers for access control.
+- Use proper authentication and authorization mechanisms (e.g., sessions, tokens).
+- If headers must be checked, combine them with server-side checks.
+- Don’t leak hints or secrets in HTML comments.
diff --git a/open_redirect/README.md b/open_redirect/README.md
new file mode 100644
index 0000000..eb4b920
--- /dev/null
+++ b/open_redirect/README.md
@@ -0,0 +1,14 @@
+# Open redirect
+
+## How We Found It
+On the footer, there is buttons to go to the twitter, instagram and facebook page of 42. to redirect the links in the href are `?page=redirect&site=<service>`. so we tried changing the site to something else and got a flag
+
+## Utility of It
+- Allows attackers to redirect users to arbitrary URLs.
+- Can be used for phishing, token theft, or triggering unexpected behavior (like flag reveals in CTFs).
+- Often underestimated but can be chained with other bugs.
+
+## How Can We Patch It
+- Only allow redirects to a whitelisted set of domains.
+- Don’t take the redirect target directly from user input.
+- Consider showing a confirmation page before redirecting.
diff --git a/sensitive_file_exposure/README.md b/sensitive_file_exposure/README.md
new file mode 100644
index 0000000..b51aa87
--- /dev/null
+++ b/sensitive_file_exposure/README.md
@@ -0,0 +1,20 @@
+# Sensitive file exposure 
+
+## How We Found It
+in the `/robots.txt` page, there is a page called `/whatever` that is disallowed. when we go to `/whatever`, there is a file called htaccess that we can download. in this file there is just one line : 
+```
+root:437394baff5aa33daa618be47b75cb49
+```
+that looks like a user login and a password hashed using md5, so we decrypted it and got the password `qwerty123@`. This is intresting but where shoud we use it ?
+there is a page called `/admin`, on this page, there is a login and password prompt, when we enter the username and password found earlier, we get a flag.
+
+## Utility of It
+- Leaks credentials that can be used to access restricted areas (like /admin).
+- Can lead to full system compromise if reused elsewhere.
+- Highlights bad practice of storing sensitive data in web-accessible paths.
+
+## How Can We Patch It
+- Never expose sensitive files like `.htaccess`, `.env`, `config.php`, etc.
+- Properly configure the web server to deny access to such files.
+- Avoid storing plaintext or weakly hashed passwords in accessible locations.
+- Use strong hashing algorithms (e.g., bcrypt) and limit access to admin interfaces.