🌲Securing API Servers

---

Cross Origin Resource Sharing (CORS)

A grosso modo, CORS (Cross-Origin Resource Sharing) es una política de seguridad de los navegadores que:

❌ Evita que una web cargada desde un dominio (ej: evil.com) haga peticiones a otro dominio (ej: api.victima.com) sin permiso.

---

💥 ¿Por qué existe?

Para proteger a los usuarios del robo de datos o ejecución de acciones no autorizadas desde scripts maliciosos.

¿Cómo se permite?

El servidor (api.victima.com) debe responder con headers especiales como:

Access-Control-Allow-Origin: https://app.segura.com

Con eso le dice al navegador:

"Sí, permito que este origen me consulte."

• CORS PERMITE bloquear que un sitio no permitido en la API no pueda compartir recursos maliciosos a otros dominios victimas.

¿Qué hace Cross-Origin-Resource-Policy?

Evita que otros sitios (otros orígenes) incrusten o carguen recursos desde tu servidor si tú no lo permites.

Piensa en esto como una muralla contra ataques tipo CSRF a imágenes, side-channel y data leaks a través de recursos compartidos.

🧱 Valores permitidos y su explicación

Valor	¿Qué permite?
same-origin	🔒 Solo el mismo origen puede cargar el recurso.
same-site	🟡 Orígenes del mismo sitio (subdominios incluidos, ej. a.evil.com, b.evil.com) pueden cargarlo.
cross-origin (o *)	🌐 Cualquier origen puede cargar el recurso.
null	❌ No válido aquí. No es un valor permitido para este header. Si lo pones, se ignora o puede lanzar error.

Quiz:

Question 1
What changes behavior based on CORS settings?
The malicious visitor
The server
The web browser
Correct answer.
Web crawlers

Question 2
The Cross Origin Site Policy header governs:
A data limit that cannot be exceeded
Whether content can be mixed between locations
Correct answer.
The history of website content for reference
Legal references for data handling

Question 3
The Access-Control-Allow-Origin header defines:
Which domains are allowed to request data
Correct answer.
Which user accounts can access the site
What is allowed to go into browser history
A cache of which user agents were allowed access

---

Error Disclosure:

• Error generico, exista o no exista el recurso un 404 en github es retornando y es un buen ejemplo de buena practica.

Quiz:

Question 1
Who does NOT benefit from verbose, detailed technical error messages?
Customer support
Malicious actors
Developers
Customers
Correct answer.

Question 2
What is NOT an example of an Error Disclosure?
Tech stack information
Specific libraries
Simple, non-detailed error message
Correct answer.
Debug information

Question 3
Exceptions should be caught:
Early, when anything is unexpected
Correct answer.
Only when the logic can't continue without it
By customer request, when they have issues
In development

Information Leak

• Google dork: “Uvicorn CVE”

Otro ejemplo:

Quiz:

Question 1
What Header is NOT a concern for sending to clients
Cache-Control
Correct answer.
X-Version
X-Powered-By
Server

Question 2
What is a known vulnerability commonly called?
Malware
Bug
Ticket
CVE
Correct answer.

Question 3
Response Headers are:
Rarely needed data for an API
Information sent to all client applications
Correct answer.
Secure communication to a client from a server
Exclusive API data implementations

Insecure Cookies:

• Cookies are storing data on a customer's computer, and secure cookies are ones that are created that don't restrict the access to anybody who might want to read that data.

• When a cookie is created, it has certain security settings that can be created, such as the Secure option, the HTTP Only option, and then restricting what sites are allowed to read the cookie.

Quiz

Question 1
Insecure Cookies are:
Protected data
Server side data that can easily be retrieved
Easily harvested data on customers' machines
Correct answer.
A treat that tastes great and makes you feel guilty

Question 2
Cookie Data should be treated as:
Logic driving state variables
Internal trusted data
Secure state storage
Untrusted input
Correct answer.

Question 3
Which of these is NOT a security flag for cookies:
SSL
Correct answer.
Secure
Httponly
maxAge

Path Traversal:

Quiz:

Question 1
Path Traversal vulnerabilities are:
Course correction from a school counselor on life path choices
Moving paths symlinks across servers
Typing in different paths in the URL
Any file access that wasn’t intended
Correct answer.

Question 2
The parameter definition in a spec can help prevent path traversal by:
Specifically disallowing filenames
Blocking lengthy bypasses of encoding
Correct answer.
Enabling the “No path changes” option
Updating the known paths list

Question 3
Files that are ok to be kept at the webroot are:
Only the ones to be served in responses
Correct answer.
Only files from the applications code repository
Any system and configuration files used for the web service
The same files copied and pasted from each environment

---

Rate Limit:

• HTTP Status: 429 too many requests

• try captCHA that will make the difference.

• Bloquear luego de muchas requests per second.

• 4 digits es apura fuerza bruta viendo cual posible combinacion retorne un 200 o un 302

• user enumeration es tirar lo mismo en busca de diferencias en la response received, length de las respuestas con el fin de poder ver si hay diferencias y de esta manera ir identificando users existentes, etc.

• scrapping

Resumen de los Tech Tips contra Rate Limits:

1. Evita operaciones SQL para manejar throttling

   • 🔒 Pro: Son lentas y pueden ser explotadas (DoS, SQLi).

   • 🧠 Idea: Usa almacenamiento en memoria (como Redis o Memcached), mucho más rápido.

2. Evita operaciones en disco

   • 🔒 Pro: Leer/escribir en disco es lento y escalable solo hasta cierto punto.

   • 🧠 Idea: Guarda el conteo de peticiones en memoria, no en archivos.

3. Incluye la IP junto con el usuario

   • 🔒 Pro: Previene que varios atacantes usen un solo user/token desde múltiples IPs.

   • 🛠️ Contra para atacante: Cambiar de IP ya no basta, también necesita cuentas nuevas.

4. Usa caché para respuestas repetidas (misma query)

   • 🔒 Pro: Si muchos usuarios hacen la misma query, mejor devuelve una respuesta cacheada.

   • 🛠️ Contra para atacante: Puede dificultar fuzzing si siempre se recibe la misma respuesta cacheada.

Quiz:

Question 1
User Enumeration is:
Determining valid from invalid accounts through brute force.
Correct answer.
Getting an accurate count of users on the API
Monitoring the concurrent users count vs limitations
Enforcing an endpoint quota on a user

Question 2
The Standard HTTP Status code for “Too many requests” is
411
420
429
Correct answer.
414

Question 3
Which of the following is NOT a vector for an application layer DOS?
Coordinated Botnet activity on an endpoint
XSS links on 3rd party websites point to your endpoint
Legitimate User Activity beyond an environments capacity
Mass DNS reflection attack
Correct answer.

---