Application security

Personal data protection

Data protection principles

• Minimization, only collect and store strictly necessary data.
• Use limitation, use data only for the declared purpose.
• Limited retention, delete data when it is no longer needed.
• Security, protect data with appropriate technical measures.

Mercado Libre sensitive data:

This data is classified as personally identifiable information (PII) and must be encrypted at rest, masked in logs and restricted access; the following are some examples of this type of data:

• Emails
• Phone numbers
• Shipping address
• Identity document
• Any other data for exclusive use by the user.

Required practices:

• Encrypt PII data at rest, use AES-256 or equivalent.
• Mask logs, do not log complete e-mails, phone numbers and identity documents.
• Only users with the appropriate roles and/or permissions can access this data.
• Access log that allows identifying who accessed sensitive data and what they did with it.
• Establish a data retention policy.
• Right to deletion, ability to delete data if the user requests it.

Let's see what insecure vs secure handling of personal data looks like:

In the database:

PERSONAL DATA SECURITY: STORAGE

❌ INCORRECT: WITHOUT ENCRYPTION

+--------------+------------------+------------------+
| buyer_id     | email            | phone            |
+--------------+------------------+------------------+
| 12345        | juan@email.com   | 1155551234       |
+--------------+------------------+------------------+
⚠️ CRITICAL RISK: If the DB is hacked, all personal data is exposed.

✅ CORRECT: WITH ENCRYPTION (ENCRYPTED)

+--------------+------------------+------------------+
| buyer_id     | email_encrypted  | phone_encrypted  |
+--------------+------------------+------------------+
| 12345        | gAAAAABl2K8...   | gAAAAABl2K9...   |
|              | [encrypted]      | [encrypted]      |
+--------------+------------------+------------------+
✅ ROBUST SECURITY: Even if the DB is hacked, the data is protected and unreadable.

In logs:

❌ INCORRECT:

[2026-01-15] Order created for: juan@email.com, tel: +5491155551234

⚠️ Anyone with log access can see personal data

✅ CORRECT:

[2026-01-15] Order created for: j***@***.com, tel: ***1234

Or better:
[2026-01-15] Order 12345 created for buyer_id: 67890

✅ Personal data is obfuscated or replaced
by IDs, protecting privacy.

References

• OWASP Data Protection: Best practices for data protection.
• PCI DSS: Security standard for card data.
• CWE-359: Exposure of Private Personal Information: Technical documentation on exposure of private personal information.
• OWASP Top 10 - A02:2021 Sensitive Data Exposure: Documentation on sensitive data exposure, includes PII.

Glossary

Term	Meaning
PII	Personally Identifiable Information - Data that identifies a person (name, email, phone, document).
Encryption at rest	Encrypting data when it is stored in the database (not only in transit).
Masking	Hiding part of sensitive data (e.g.: showing j***@***.com instead of the full email).
Minimization	Principle of only storing strictly necessary data.
Retention	How long data is kept before deleting it.

Data validation

Validation principles

• Validate both frontend and backend, never rely solely on client-side validations.
• Use allowlist and not blocklist, define what is allowed and not what is prohibited.
• Validate type and format, verify that the data is of the expected type.
• Validate ranges, accept only the necessary number of characters by setting logical limits.
• Reject invalid data without attempting to "fix" malformed data and managing error handling to avoid delivering extra technical information in responses.

Validations by type:

• Strings: maximum length, allowed characters, encoding.
• Numbers: Type (integer/decimal), range, sign.
• Emails: valid format, length.
• URLs: allowed protocol (HTTPS), valid domain.
• IDs: validate expected format, existence.
• Dates: ISO format, logical range.

An unvalidated field can be an entry point for SQL injection, XSS, or command execution. Review these examples:

Validate in backend (not just frontend):

❌ INCORRECT: FRONTEND ONLY

JavaScript (browser)
  if (email.includes("@")) { submit(); }

⚠️ Problem: The attacker can bypass JavaScript with external tools.

✅ CORRECT: FRONTEND + BACKEND

Browser (JavaScript)
  if (email.includes("@")) { submit(); }

Server (Python)
  if not is_valid_email(email):
      return error("Invalid email")

✅ Double security layer: The server always validates data integrity.

Allowlist vs Blocklist:

❌ INCORRECT: BLOCKLIST (what is prohibited)

# Prohibit dangerous characters
if "<script>" in input or "DROP TABLE" in input:
    reject()

⚠️ Problem: Attackers always find ways to bypass the blocklist.

✅ CORRECT: ALLOWLIST (what is allowed)

# Only allow what we expect
if not re.match(r"^[a-zA-Z0-9_]{3,20}$", username):
    reject()

✅ If it does not exactly match what is allowed, reject.

Validate type and format:

❌ INCORRECT: WITHOUT TYPE VALIDATION

# Accept anything
order_id = request.get("order_id")
order = get_order(order_id)

⚠️ Problem: What happens if order_id = "abc" or
   "1; DROP TABLE orders"?

✅ CORRECT: WITH VALIDATION

order_id = request.get("order_id")

# Validate that it is a number
if not order_id.isdigit():
    return error("Invalid order ID")

order = get_order(int(order_id))

✅ By enforcing the data type, you avoid injections and
   unexpected execution errors.

References

• OWASP Input Validation: Comprehensive guide on input validation.
• OWASP SQL Injection Prevention: How to prevent SQL injection.
• OWASP XSS Prevention: How to prevent Cross-Site Scripting.
• OWASP Command injection: How to prevent command injection.
• CWE-20 (Input Validation): Documentation on incorrect validation and definition of its risk.

Glossary

Term	Meaning
Validation	Verifying that received data has the expected format and values.
Sanitization	Cleaning input data by removing dangerous characters.
SQL Injection	Attack where malicious SQL code is injected through input fields.
XSS	Cross-Site Scripting - Attack where malicious JavaScript is injected into web pages.
Command Injection	Attack where operating system commands are injected.
Allowlist (White list)	Defining WHAT is allowed (more secure).
Blocklist (Black list)	Defining WHAT is prohibited (less secure, can always be bypassed).
Regex	Regular Expression - Pattern for validating text format.

Error handling

• Messages must be generic for the user, technical details must not be exposed.
• Details only in logs, stack traces and technical errors go to internal logs.
• It is good practice to use error codes that allow investigation without exposing details.
• Consistency using the same messages for similar errors.

Information NOT to expose

• Stack traces or exceptions.
• System file paths.
• SQL queries or database errors.
• Table or column names.
• Software or framework versions.
• Internal IPs or server names.
• Whether a user exists or not (on login).

A detailed error message is gold for an attacker: it reveals paths, technologies and internal logic. Compare these scenarios:

References

• OWASP Input Validation: Comprehensive guide on input validation.
• OWASP SQL Injection Prevention: How to prevent SQL injection.
• OWASP XSS Prevention: How to prevent Cross-Site Scripting.
• OWASP Command injection: How to prevent command injection.
• CWE-20 (Input Validation): Documentation on incorrect validation and definition of its risk.

Glossary

Term	Meaning
Stack Trace	Technical error detail that shows lines of code, file paths, etc.
Information Disclosure	Information leakage - Revealing internal system data in error messages.
Generic error	Error message that does not reveal technical details (e.g.: "An error occurred").
Logging	Saving a record of events and errors internally (not shown to the user).

Notification security (WebHooks)

Without adequate protection of this endpoint, an attacker could:

• Send fake notifications.
• Send and process fraudulent data.
• Perform a denial of service DoS.

That is why we recommend implementing the following requirements:

Use HTTPS mandatorily

❌ INCORRECT:

http://tuapp.com/webhooks/meli

Problem: Notifications travel unencrypted. An attacker can intercept and read the data.

✅ CORRECT:

https://tuapp.com/webhooks/meli

Notifications travel encrypted. No one can read the content in transit.

When you configure your application in the application manager, the callback URL must use HTTPS.

Validate that the notification comes from Mercadolibre

Mercadolibre sends notifications from these IPs:

• 54.88.218.97
• 18.215.140.160
• 18.213.114.129
• 18.206.34.84
• 35.236.253.169
• 35.245.91.34
• 35.245.20.104
• 35.186.182.146

The flow with the validation should look like this:

[Placeholder: diagrama-validacion-ips-webhook.png]

Important: IPs may change. Always check the documentation for the updated list.

Another validation option is to query the resource. The safest way to validate a notification is to not trust the webhook data, but to use the notification as a "notice" and then query the MercadoLibre API directly, it would look something like this:

SECURE FLOW:
                            |
  1. You receive notification: |  {
                            |    "resource": "/orders/123",
                            v    "user_id": 789 ...
                               }

  2. Respond HTTP 200 immediately
     (confirm receipt)
                           |
                           v
  3. Queue for async processing
                           |
                           v
  4. Query MELI API directly:
     GET https://api.mercadolibre.com/orders/123
     with YOUR access_token
                           |
                           v
  5. Use the data from the API response
     ⚠️ (NOT the webhook data)

Respond quickly

MercadoLibre expects an HTTP 200 response in less than 500 milliseconds:

❌ IF YOU DON'T RESPOND IN TIME:

Attempt 1 --> Your server (timeout) --> MELI retries
Attempt 2 --> Your server (timeout) --> MELI retries
...
Attempt 8 --> Your server (timeout) --> MELI disables your
                                        notifications

Result: You lose notifications and must reactivate
           manually.

✅ CORRECT PATTERN:

1. Receive webhook
2. Save to queue (Redis, RabbitMQ, database)
3. Respond HTTP 200 immediately
4. Process the queue asynchronously

    Webhook --> +-----------------+
                | Receive         | --> HTTP 200 (immediate)
                | and queue       |
                +--------+--------+
                         |
                         v
                +-----------------+
                | Queue           |
                | (async)         |
                +--------+--------+
                         |
                         v
                +-----------------+
                | Process         | --> Query MELI API
                | (worker)        | --> Update your DB
                +-----------------+

Protect against abuse or excessive consumption

❌ WITHOUT PROTECTION:

  Attacker sends 10,000 requests/second
                   |
                   v
          Your server becomes saturated
                   |
                   v
    You cannot process real MELI webhooks

✅ WITH PROTECTION: Implement Rate Limiting

+------------------------+------------------------+
| Measure                | Suggested configuration|
+------------------------+------------------------+
| Rate limit per IP      | 100 req/minute max     |
| Connection timeout     | 30 seconds max         |
| Max. payload size      | 1 MB max               |
| IP blocking            | After 10 invalid req.  |
+------------------------+------------------------+

✅ By limiting traffic, you ensure that your server
   resources are always available for Mercado Libre.

References

• MELI - Notifications: official notifications documentation on Mercadolibre.
• Webhook security: Risks associated with webhooks.

Glossary

Term	Meaning
Webhook	Automatic notification that MELI sends to your server when something changes (new order, payment, etc.).
Payload	In this context, the data that comes within the notification (the JSON content).
IP Whitelist	List of allowed IPs - only accept connections from those specific IPs.
Rate Limiting	Limiting how many requests per minute your server can receive.
Async / Asynchronous	Processing something in the background, without making the requester wait.
DoS	Denial of Service - Attack that saturates your server with many requests.

Protection against abuse

Rate limiting in the integrating application (suggestion)

• For login 5 attempts / 15 min.
• New account registration 3 attempts / hour / IP.
• Sensitive APIs / endpoints 30 - 60 requests / min (to be considered according to business needs).
• General APIs / endpoints 100 - 200 requests / min.

❌ WITHOUT RATE LIMITING:

Attacker makes 10,000 requests per minute
Your server becomes saturated
Or: Your MercadoLibre account is blocked for exceeding limits

✅ WITH RATE LIMITING:

+----------------------------+--------------------+
|     RECOMMENDED RATE LIMITS                     |
+----------------------------+--------------------+
| Endpoint                   | Limit              |
+----------------------------+--------------------+
| Login                      | 5 attempts/15 min  |
| Account registration       | 3 attempts/hour/IP |
| Sensitive APIs             | 30-60 req/min      |
| General APIs               | 100-200 req/min    |
+----------------------------+--------------------+

Request 101 in 1 minute:
   -> HTTP 429 Too Many Requests
   -> Header: Retry-After: 30

Additional protection

• Implement a CAPTCHA system that activates especially after N failed attempts or when suspicious behavior is detected.
• Temporary IP or account blocking in case of abuse.
• Bot detection through behavior pattern analysis.

References

• OWASP Blocking Brute Force: How to prevent brute force attacks.
• OWASP Denial of Service: DoS protection guide.
• Rate Limiting Best Practices: Best practices for rate limiting.

Glossary

Term	Meaning
Rate Limiting	Limiting how many requests a user/IP can make per minute.
Brute Force	Attack that tries many combinations until finding the correct one (e.g.: passwords).
CAPTCHA	Test to verify that the user is human and not a bot.
DoS / DDoS	(Distributed) Denial of Service - Attack that saturates the server with requests.
Scraping	Automated data extraction from a website.
BOT	Automated program that makes requests without human intervention.
HTTP 429	Response code that means "Too Many Requests".
Throttling	Reducing response speed when there are many requests.

Dependency Security

It is recommended to:

• Perform regular scans to check known vulnerabilities at least weekly; there are different solutions on the market that could help in this process: Snyk, Owasp dependency-check, npm audit, renovate, among others.
• Apply identified security updates as soon as possible.
• It is recommended to use specific versions and not open ranges.
• It is important to evaluate a dependency at the security and maintenance level before using it; this can be done using the tools mentioned above.
• It is also useful to stay up to date with news related to common dependencies; the companies behind these dependency analysis software often allow subscribing to their newsletters.

How can we verify this? Let's look at some examples in common languages:

Language	Tool	Command
Python	Safety, pip-audit	safety check or pip-audit
Node.js	Npm audit	npm audit
Java	OWASP dependency-check	maven/gradle plugin
Other languages	Snyk	snyk test

Result example:

$ npm audit
found 3 vulnerabilities (1 low, 1 moderate, 1 high)

+---------------+---------------------------------------+
| high          | Prototype Pollution in lodash         |
+---------------+---------------------------------------+
| Package       | lodash                                |
+---------------+---------------------------------------+
| Patched in    | >=4.17.21                             |
+---------------+---------------------------------------+
| Dependency of | your-app                              |
+---------------+---------------------------------------+
| Path          | your-app > lodash                     |
+---------------+---------------------------------------+

References

• OWASP Dependency Check: Tool for detecting vulnerabilities in dependencies.
• Snyk: Security platform for dependencies.
• npm audit: npm audit documentation.
• Pip-audit: Audit tool for Python.
• CWE-1104 (Unmaintained Components): Documentation on unmaintained components.

Glossary

Term	Meaning
Dependency	Third-party library or package used in your project (e.g.: requests, lodash, axios).
Vulnerability	Security flaw in the code that can be exploited.
CVE	Common Vulnerabilities and Exposures - Unique identifier for known vulnerabilities.
npm audit	Node.js command for detecting vulnerabilities in dependencies.
pip-audit / safety	Python tools for detecting vulnerabilities in dependencies.
Patch	Update that fixes a vulnerability.

Next: Monitoring.