DEV Community: Nicolás

Do you know the difference between Terraform Provider and Module?

Nicolás — Mon, 20 Jul 2026 15:00:00 +0000

Terraform is one of the most popular Infrastructure as Code (IaC) tools in the world. It allows us to provision infrastructure resources programmatically and declaratively, meaning we define what we want, and Terraform figures out how to build it.

We do not need to worry about the specific API calls required to provision resources in AWS, GCP, Azure, or other platforms because Terraform abstracts that complexity. However, to use it effectively, we must understand two core components: Providers and Modules.

Providers - The translator layer

Imagine you want to deploy an EC2 instance in AWS. To do this, Terraform needs to know how to authenticate with your AWS account and how to translate your configuration code into the specific API calls that AWS understands.

Providers act as these translators. They are plugins that tell Terraform how to interact with external platforms like AWS, GCP, Azure, GitHub, etc. They encapsulate all the platform-specific logic, allowing you to focus purely on defining your resources.

The Terraform Registry

Terraform relies on an extensive plugin system that you can explore in the Terraform Registry (https://registry.terraform.io/)

Using Providers

Using a provider is super simple:

provider "aws" {
  region = "us-west-2"
}

As a best practice, providers are usually defined in a dedicated providers.tf file.

Once the provider is set up, Terraform knows exactly how to read an AWS resource block and interact with the AWS API to deploy it:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Modules - Reusability is served

In traditional programming, we follow the DRY principle (Don't Repeat Yourself) to avoid repeating code over and over. So, we use functions or classes to group collections of related logic, variables, and operations into reusable blocks. By passing different parameters to these functions, we can execute the same behavior in various contexts without duplicating the underlying code.

Terraform modules apply this principle to infrastructure. Just as a function prevents us from rewriting the same script, a module prevents us from rewriting the same resource blocks.

They allow us to group a collection of related resources, think of an EC2 instance, its security groups, its volumes...., into a single, standardized package that can be deployed repeatedly just by changing the input variables.

Using modules

Imagine that we need to deploy S3 buckets for different departments within the company. Instead of typing over and over the multiple Terraform resources to define the buckets, we could create a module that simply accepts a name and environment as parameters:

# modules/secure_bucket/main.tf
variable "bucket_name" {
  type = string
}

variable "environment" {
  type = string
}

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name

  tags = {
    Environment = var.environment
    ManagedBy   = "Terraform Module"
  }
}

and then, we would call it as:

# main.tf
module "financial_data_bucket" {
  source = "./modules/secure_bucket"

  bucket_name = "company-financial-data-2026"
  environment = "Production"
}

module "app_assets_bucket" {
  source = "./modules/secure_bucket"

  bucket_name = "company-app-assets-2026"
  environment = "Development"
}

Conclusion

As a takeaway, let's remember that:

Providers: provide the connectivity components to external platforms by translating your Terraform code to the right API calls.
Modules: containers of multiple resources used together. Allows reusability.

How to prevent member accounts from leaving your AWS organization

Nicolás — Sun, 19 Jul 2026 15:00:00 +0000

When you start in AWS, you probably start small.

You open an account and start trying out services, building PoCs, and understanding how everything works before committing to designing environments to host your production workloads.

Other teams hear that you have AWS access and start requesting access to the same account to also build PoCs for their specific use cases. But soon the account starts to get messy: resources from different teams are scattered everywhere, and teams see their PoCs impacted by others deleting resources. So, you start looking for a better solution.

You then create a second standalone account, and then a third, and a fourth. You grant access to each team so that everyone has environments completely isolated from each other.

However, you soon realize that dealing with separate billing, security, and governance across multiple accounts is a pain, so you start looking for a better alternative again.

You start exploring AWS Organizations. You create one org and invite each of the standalone accounts so you can now benefit from consolidated billing, access to org-wide discounts, enhanced governance, and improved security.

But just as easily as the AWS accounts joined, they can also leave your organization, which represents a significant security problem.

Think about the consequences of having an AWS account with access to sensitive information suddenly becoming independent. You lose all your governance and security controls that were implemented at the organization level.

So, you start thinking about implementing security controls to prevent this.

When it comes to security, the best approach is having a layered defense. Just in case one fails, another is active to protect the fort.

The first control that we can implement is tied to the Principle of Least Privilege. Closing an account or leaving an organization are highly sensitive operations, and nobody should have enough permissions to perform them. It could be argued that you could have a handful of privileged users in case of an emergency, and that's fine as long as you accepted the risk. Just make sure that those privileged users are highly restricted and monitored.

The specific permissions you should restrict are:

organizations:LeaveOrganization
account:CloseAccount

So, simply don't add them to any IAM policy.

The second control would be at the org level via a Service Control Policy (SCP). These are organizational policies that let us control the maximum permissions principals can have across the organization. They act as guardrails and are enforced in every single AWS account in your organization, assuming you have attached them at the root level.

The following SCP blocks principals in your organization from closing accounts and from attempting to remove member accounts from the organization.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BlockOrgSensitiveActions",
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization",
                "account:CloseAccount"
            ],
            "Resource": "*"
        }
    ]
}

The good thing is that if you created an AWS Organization via the AWS console after July 10, 2026, an SCP is created for you and attached at the root level to prevent this very same concern. If you did it before that date, or used the API, you will still need to manually configure the SCP.

Do you pin your base images in Dockerfile?

Nicolás — Sat, 18 Jul 2026 12:48:39 +0000

TL;DR

Using tags like latest or numeric versions (3.23.5) in your Dockerfile is dangerous because they are mutable and can change without warning.

These changes can break your application in production or expose you to supply chain attacks if the base image is compromised.

It is crucial to always pin your base image to a specific SHA (e.g., FROM alpine@sha256:...) since it is the only way to guarantee immutability.

Intro

If you work in tech, you've probably heard of Docker and the famous containers. If not, the main thing you need to know is that it's a technology that allows you to package applications into containers, thus solving the legendary "it works on my machine, but it won't even open on yours" problem.

These containers run our application from an image, which includes our code and everything it needs to work.

To build this image, we use a file called Dockerfile.

So what is the Dockerfile?

The Dockerfile is just a plain text file. It doesn't even use a specific extension. You simply need to name the file Dockerfile for Docker to recognize it.

In this file, we define the instructions we want Docker to follow to create an image. Something along the lines of:

Use this base image
Run commands XYZ
Remove these services
and so on and so on

Once we're done, creating the image is super simple. We just need to open the CLI, navigate to the location where the Dockerfile is, and run the command docker build . -t <Name>

The Base Image

To build any image in Docker, we start with a base image. This image will be like a canvas on which we will install our application and add our own dependencies.

It is important to keep in mind that it's not a blank canvas: the image already comes with pre-installed software that may or may not be useful to us. If it isn't, the best practice is to uninstall it to reduce the attack surface, but that's a topic for another post.

For example, if we run the command with the following code, Docker will create a local image starting from the latest available version of alpine:

FROM alpine:latest

# Print to console to verify execution
CMD ["echo", "Hi!"]

The Problem with Selecting Versions

There are three main ways to select a base image version: using latest, a specific version, or the hash identifier (SHA).

You've probably already come across many tutorials or blogs that use base images like this:

FROM alpine:latest
FROM alpine:3.23.5

The reason why is no mystery: it's simple, readable, and it's easy to understand which version is being used.

If we use latest, we ensure that at build time, the most recent version is used, and if we use the second option, we make it explicitly clear that we want to use version 3.23.5.

However, selecting the base image version in these ways can open the door to two major security risks:

Supply chain attacks
Introduction of vulnerabilities

(If you've used GitHub Actions before, this problem will be familiar to you).

The problem with using latest is that, as its name suggests, it can change from one day to the next. This can cause our application to stop working due to the introduction of breaking changes.

Even worse, if an attacker manages to compromise the accounts of the maintainers, they could publish a malicious version that would be downloaded by pipelines using latest.

We might think that specifying a version would free us from this problem, but that's not the case. A version like 3.23.5 is actually a tag, just like latest, that points to specific code.

These tags are mutable, which means maintainers could make changes such as updating the base image to patch vulnerabilities and have the 3.23.5 tag point to this new code.

The solution to these problems is to pin the base image to a specific SHA.

Always Pin the Image

The only way to achieve immutability is through this method. This guarantees that we always use exactly the same version, since any minor change in the image's code will produce a different SHA.

There is no excuse not to use it.

FROM alpine@sha256:fd791d74b68913cbb027c6546007b3f0d3bc45125f797758156952bc2d6daf40 # 3.22.5

It is a good practice to include a comment on the same line indicating the version the SHA refers to.

Terraform - How to prevent sensitive data from ending up in the .tfstate

Nicolás — Sat, 11 Jul 2026 18:19:50 +0000

TL;DR

By default, Terraform stores all secrets in plaintext within its state file (.tfstate). The traditional sensitive = true argument only hides the data in the CLI, but does not protect it in the state. The definitive solution to securely inject secrets at runtime without leaving a trace in the state is to combine ephemeral = true variables with the write-only arguments of each provider.

Intro

Terraform is one of the most popular IaC (Infrastructure as Code) tools among DevOps teams. And it's no surprise; it's portable, has a wide catalog of providers, and is relatively easy to use.

With Terraform, we can deploy infrastructure, keep track of its configuration, and finally, delete it when it is no longer needed, all with just a few commands.

To properly work, Terraform needs to know the resources it has deployed as well as their configuration. To achieve this, it relies on a state file with the .tfstate extension that acts as a resource inventory.

This file is automatically managed by Terraform and reflects the state of our infrastructure. By default, the state is saved in plaintext, so anyone with access to it can read it without problems.

This represents a security problem for two reasons:

It reveals the design of the environment. It allows knowing the infrastructure, the resources, how they connect to each other, as well as their configuration.
It implies potential access to secrets.

We know that Terraform needs to store the value of these secrets to check if they change, but is there a safer way to manage them and prevent them from ending up exposed in the state?

What Does the Documentation Say?

As good engineers, our first instinct is to check the official documentation (or interrogate our trusted AI), which is quite clear about this:

If you add secret values directly to your configuration, Terraform stores those secrets in its state and plan files.

Fortunately, the documentation also points us to two key arguments:

sensitive: Tells Terraform to hide the value of a variable or output in the CLI.
ephemeral: Allows handling values at runtime without persisting them in the state.

It should be noted that both arguments are not mutually exclusive, so you can use them together to ensure that a secret neither appears in the terminal nor leaves a trace in the state.

But, if we don't store the secret's value, how does Terraform know when to update it? When using ephemeral, write-only arguments defined by each provider are also typically used. These arguments allow passing secrets, which are only available during runtime, to the resources without them becoming part of the state.

write-only arguments usually end with the suffix _wo and have their corresponding version argument _wo_version. The latter are used by Terraform to know when to update the secrets, so we just have to increment the value of that version for Terraform to detect the change and apply the new secret.

True to the motto of "Trust, but verify", let's move from theory to practice to check it for ourselves.

Scenario 1: Hardcoded Secret

The first scenario is to hardcode secrets directly into the Terraform configuration. As we have already mentioned, this causes them not only to be stored in the state, but also allows anyone with access to the configuration itself to read the secret effortlessly.

As an example, let's create a parameter within Parameter Store in AWS. These parameters can contain anything, since what they store is a string, and those things can include a secret, like an API key to access some platform.

resource "aws_ssm_parameter" "payment_api_key" {
  name        = "/production/payment-gateway/api-key"
  description = "API Key for processing payments securely"
  # "SecureString" ensures AWS encrypts this value at rest
  type        = "SecureString"
  # The value is passed in securely via the variable
  value       = "MiSuperSecreto876#"
  tags = {
    Environment = "production"
    Application = "billing"
  }
}

This code creates a parameter named /production/payment-gateway/api-key of type SecureString (encrypted with KMS), applies two tags (Environment=production and Application=billing) to it, and defines the value of the secret: MiSuperSecreto876#.

If we run a terraform plan, we see how the secret appears masked and in its place we find value = (sensitive value).

But, didn't we mention earlier that, in order to hide a secret in the CLI, we had to explicitly use the sensitive = true argument?

That's correct. However, there is a default behavior that has our backs:

Terraform also treats any expressions that reference a sensitive variable or output as inherently sensitive.

Let's take a look at the state:

"id": "/production/payment-gateway/api-key",
"name": "/production/payment-gateway/api-key",
"region": "us-east-1",
"tags": {},
"tags_all": {},
"tier": "",
"type": "SecureString",
"value": "MiSuperSecreto876#"

As expected, Terraform has stored the secret in the state.

Scenario 2: The `sensitive` argument to the rescue (or almost)

For the following scenario, we're going to apply some best practices. Instead of leaving the secret exposed in the code for anyone to see, we will move it to an external variable and use the sensitive=true argument:

variable "payment_api_key_value" {
  description = "The secret value for the payment API key"
  type        = string
  sensitive   = true  
}

resource "aws_ssm_parameter" "payment_api_key" {
  name        = "/production/payment-gateway/api-key"
  description = "API Key for processing payments securely"
  type        = "SecureString"
  # 2. Reference the sensitive variable
  value       = var.payment_api_key_value
  tags = {
    Environment = "production"
    Application = "billing"
  }
}

Upon running a terraform plan, the terminal output will be identical to the first scenario: the secret will not be shown in the CLI and Terraform will mask it completely.

However, the state still contains the secret:

"id": "/production/payment-gateway/api-key",
"name": "/production/payment-gateway/api-key",
"region": "us-east-1",
"tags": {},
"tags_all": {},
"tier": "",
"type": "SecureString",
"value": "MiSuperSecreto876#"

It is proven then that sensitive only hides the value in the CLI, but Terraform still saves it in the .tfstate so it can track changes.

Scenario 3: Secrets in an external platform

One of the most highly recommended practices when using secrets in Terraform is storing them in an external manager like AWS Secrets Manager and consuming them at runtime.

For this scenario, I've used HashiCorp Vault locally with the same Terraform code as the previous scenario:

variable "payment_api_key_value" {
  description = "The secret value for the payment API key"
  type        = string
  sensitive   = true  
}

resource "aws_ssm_parameter" "payment_api_key" {
  name        = "/production/payment-gateway/api-key"
  description = "API Key for processing payments securely"
  type        = "SecureString"
  value       = var.payment_api_key_value
  tags = {
    Environment = "production"
    Application = "billing"
  }
}

And we will execute it using:

terraform apply -var="payment_api_key_value=$(vault kv get -address="http://127.0.0.1:8200" -field=password secret/myapp/database)"

Which produces a plan similar to the previous ones with the secret masked.

However, the secret is still visible in the state:

"attributes": {
    "description": "API Key for processing payments securely",
    "id": "/production/payment-gateway/api-key",
    "name": "/production/payment-gateway/api-key",
    "region": "us-east-1",
    "tags": {},
    "tags_all": {},
    "tier": "",
    "type": "SecureString",
    "value": "PasswordSuperSecretaDeVault#",
  }

Scenario 4: Using `ephemeral` for the win

In the last scenario, we are going to test how the ephemeral argument works. As we mentioned earlier, this argument prevents Terraform from storing the secret in the state.

To start, let's add ephemeral=true to our variable:

variable "payment_api_key_value" {
  description = "The secret value for the payment API key"
  type        = string
  sensitive   = true
  ephemeral   = true  
}

Afterward, we add the write-only arguments:

resource "aws_ssm_parameter" "payment_api_key" {
  name             = "/production/payment-gateway/api-key"
  description      = "API Key for processing payments securely"
  type             = "SecureString"
  value_wo         = var.payment_api_key_value
  value_wo_version = 1
  tags = {
    Environment = "production"
    Application = "billing"
  }
}

Running terraform plan, we see how the secret is hidden thanks to sensitive (just like before).

If we apply the changes with terraform apply, we see that there is no trace of the secret in the state:

"attributes": {
    "data_type": "text",
    "description": "API Key for processing payments securely",
    "has_value_wo": true,
    "id": "/production/payment-gateway/api-key",
    "name": "/production/payment-gateway/api-key",
    "region": "us-east-1",
    "tags": {},
    "tags_all": {},
    "type": "SecureString",
    "value": "",
    "value_wo": null,
    "value_wo_version": 1
  }

Conclusions

Marking a variable as sensitive is a necessary measure to hide secrets in the CLI and logs, but it is insufficient on its own, as the secrets remain exposed to anyone with access to the state.

Consuming secrets at runtime from platforms like AWS Secrets Manager or HashiCorp Vault mitigates the risk of exposing them in the source code, but Terraform will still save the final value in the .tfstate if ephemeral is not used.

ephemeral and write-only arguments prevent secrets from ending up in the state.

Basic protections for your S3 buckets

Nicolás — Thu, 08 Jan 2026 20:12:10 +0000

S3 is one of the most popular storage services in AWS due to its simplicity. You can easily store large amounts of data for multiple purposes at a relatively low cost.

Regardless of your use case, I imagine you want your precious data to be stored securely, not only because of the trouble you could face with regulators, but because it's simply the right thing to do.

Today, I am going to talk about some basic safeguards that you can implement in S3 to help secure your data with no extra cost.

Let's start with a classic one.

Encryption

Encryption is the process of taking readable information, like your secret master plan that will make you rich, and converting it into unreablable format so that only authorized parties can access it.

I won't bore you with technical details but the key point is that encryption is important.

Most encryption you will see fall into two categories: at rest, and in transit. You may also hear about encryption in use, but that one is out of scope for this article.

Encryption at rest

In simple terms, encryption at rest deals with data that sits idle, waiting in your storage to be used. You can think of encryption at rest as having a safe where you store a top secret notebook, only authorized parties, the ones that know the code, can open the safe and access your data.

There are two main encryption methods in S3:

Server-side -> AWS encrypts the data for you before saving it on disks
Client-side -> You encrypt the data before uploading it to S3

The good thing is that buckets have encryption at rest configured by default. That way, all the objects you upload will be using Server-side encryption with AMazon S3 managed keys (SSE-S3). ALl this will be transparent to you and free of charge.

For most use-cases, SSE-S3 will be more than enough, but if you want more control, you can opt to encrypt your data using a KMS key you control.

Encryption in transit

The other encryption category we mentioned is encryption in transit. This one is in charge of protecting the data as it moves around, like when it moves from AWS to your devices as you download it.

Encryption in transit is important to guarantee the secret of communications. If there was no encryption, anyone that intercept your network traffic could read into your emails and know what your last purchase at Amazon was.

This type of encryption is achieved using asymmetric encryption, which relies on a pair of keys, a public key and a private key, to establish a secure channel between two parties for sharing information.

Think of a mailbox that anyone can drop letters into, but only the owner can open.

The mailbox slot is like the public key: anyone can use it to send a message securely. The key that opens the mailbox is the private key: only the owner has it. Even if someone watches you drop a letter into the mailbox, they cannot read it because they do not have the key.

Asymmetric encryption works the same way. If someone were to intercept your emails, the contents would appear as gibberish because that person does not have access to the private key used to protect the communication channel.

S3 buckets allow you to access your data using either HTTP (unencrypted) or HTTPS (encrypyed) endpoints. It is highly recommended to only allow access via the latter. To enforce this, you can apply the following bucket policy:

{
    "Version":"2012-10-17",              
    "Statement": [{
        "Sid": "RestrictToTLSRequestsOnly",
        "Action": "s3:*",
        "Effect": "Deny",
        "Resource": [
            "arn:aws:s3:::<yourBucket>",
            "arn:aws:s3:::<yourBucket>/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        },
        "Principal": "*"
    }]
}

Public/Private buckets

In AWS you have two types of buckets, public and private. As you may have already guessed by their names, public buckets can be accessed by anyone in the world whereas private ones are only accessible to authorized individuals.

Luckily for all, new buckets are private by default so you would need to go on the extra mile to make it public.

But hey, mistakes can happen.

To ensure you have a layered defense that prevents someone from simply turning a private bucket into a public one, consider enabling the Block Public Access feature.

Now, this feature can be enabled at three levels: bucket, account, and organization:

Block Public Access (Bucket) -> This is the level you are most likely to have enabled by default when a bucket is private.
Block Public Access (Account) -> This level blocks public access to all buckets across an account.
Block Public Access (Organization) -> If you work at a company that have a large AWS organization, you can turn this feature on at the org level so no buckets within your org can be made public.

Least privilege

You may have already come across the principle of least privilege, but if not, let me introduce it. Least privilege is a security concept that states you should grant an entity (such as a person, application, or service account) only the minimum set of permissions required to perform a specific task, and no more.

Applying this principle helps reduce the risk of accidental misuse or malicious activity. Therefore, to ensure your data is protected in S3, you must carefully scope IAM permissions so that users and services can access only the buckets and actions they truly need.

For example, if you have a bucket that stores marketing information, only the Marketing team should have access to it.

Keep in mind that least privilege is not a one-off exercise. It requires ongoing maintenance and regular audits as responsibilities change, teams are reorganized, or access requirements evolve over time.

Versioning & MFA delete

If you want to further protect your data against malicious or accidental deleition, you can enable versioning and MFA delete on buckets.

When versioning is enabled on a bucket, S3 keeps multiple versions of an object instead of permanently replacing or removing it. This allows you to recover previous versions of a file if it is deleted or modified by mistake. FYI, this feature cannot be disabled once it's enabled on a bucket and it comes with extra cost due to the multiple versions stored!

To go one extra step further, you can enable MFA Delete. MFA Delete requires users to provide multi-factor authentication (MFA) in addition to their credentials when performing sensitive operations such as permanently deleting an object version or suspending versioning on a bucket. This adds an extra layer of security by ensuring that even if credentials are compromised, critical destructive actions cannot be performed without physical access to the MFA device.

Together, versioning and MFA Delete provide an effective safeguard against data loss, whether caused by human error or malicious activity.

Top 10 AWS Security Mistakes Beginners Must Avoid

Nicolás — Sun, 04 Jan 2026 10:24:41 +0000

AWS provides a highly secure cloud platform, but that does not mean your environment is secure by default. As we explored in the AWS Responsibility Model article, security is a shared responsibility so you must do your part to ensure your resources are safe.

Most AWS security incidents do not involve advanced attackers or zero-day exploits. They happen because of basic mistakes, often made by people who are new to the cloud and still applying on-prem thinking to a very different environment.

This article walks through the top 10 AWS security mistakes beginners make, explains why they are risky, and shows how to avoid them.

1. Using the Root Account for Daily Work

Every AWS account has a root user with unlimited privileges. This is effectively "God Mode" and can do almost anything on your account. Beginners often use it because it’s easy.

Why It’s a Problem

Root user has full control over the account
If compromised, your entire account is at risk

How to Avoid It

Ensure the root user uses a strong password
Don't create access keys for the root user
Enable MFA on the root user
Create alternative access (IAM user or IAM role) for daily use

Note
It's recommended not using the root account unless absolutely necessary.

If you are experimenting with AWS, an IAM user will likely suffice for the time being. However, keep in mind that IAM users have long-term credentials such as passwords and access keys, which you should rotate regularly.

The best practice, however, is to create an use an IAM role for daily operations as roles provide temporary credentials by default.

2. Not Enabling Multi-Factor Authentication (MFA)

Passwords alone are not enough, especially in the cloud that can be accessed from anywhere in the world.

Why It’s a Problem

If credentials are leaked through phishing or reuse, attackers can log in immediately.

How to Avoid It

Adding MFA adds a second layer of defense that protects your account. Attackers would need to also get hold of the second authenticator factor to successfully log in.

Recommendations:

Enable MFA for the root account
Require MFA for privileged IAM users

3. Having public S3 buckets

S3 is one of the core services in AWS. It easily lets you store objects like files, images, videos, etc.

Why It’s a Problem

Public S3 buckets can expose:

Customer data
Backups
Logs
Intellectual property
Source code

Many major data breaches started this way. If data should not be public, explicitly prevent it.

How to Avoid It

All new buckets are private by default, but a single misconfiguration can unintentionally expose their contents to the internet.

Recommendations:

Review bucket policies carefully
Implement alerts to notify you when a bucket goes public (AWS Config, CloudTrail, EventBridge services can help)
Enable S3 Block Public Access at the account level or organization-level

Note
Having public S3 buckets is not inherently a security issue. There are valid use cases for public buckets. Just ensure the objects stored in them are truly intended to be public.

4. Overly permissive Security Groups

Security Groups are AWS’s primary network firewall, but beginners often configure them too loosely, or use the default ones because they "just work" at the cost of being highly permissive.

Why It’s a Problem

Overly permissive security groups are problematic because they significantly increase the attack surface of your environment.

When services like SSH, RDP, or databases are exposed to the internet, they become easy targets for automated scans, brute-force attacks, and exploitation attempts.

Even if the underlying application is secure, unnecessary exposure increases the likelihood of compromise.

For instance, a security group with a rule like:

SSH (22) from 0.0.0.0/0

allows SSH traffic from the entire internet.

How to Avoid It

Review inbound and outbound rules regularly
Restrict access to known IP ranges and expected ports/traffic
Use AWS System Manager Session Manager instead of SSH where possible
Monitor changes via AWS Config or a custom solution (i.e. EventBridge + Lambda)

5. Insufficient Password Policies

Weak or poorly enforced password policies are a common security gap in AWS environments, especially in accounts that were set up quickly or without security in mind.

By default, AWS allows basic password requirements unless you explicitly configure stronger rules, and many beginners never revisit these settings.

Why It's a Problem

Passwords are often the first, and sometimes only, line of defense protecting AWS accounts.

If password policies are too lenient, they become easy targets for brute-force attacks, credential stuffing, or simple guessing.

This risk is amplified when users reuse passwords across multiple services or fall for phishing attempts.

An attacker who successfully compromises a single IAM user with a weak password may gain access to sensitive resources, escalate privileges, or move laterally within the account.

How to Avoid It

Enforce strong IAM password policies (length, complexity, rotation)
Require multi-factor authentication (MFA) for all users, especially privileged ones
Disable unused IAM users and credentials

Strong password policies are a basic control, but they remain one of the most effective ways to reduce account compromise, especially when combined with MFA.

Note

Prefer IAM roles over long-lived user passwords whenever possible.

6. Insecure Use of Access Keys

AWS access keys provide programmatic access to your account and services. While they are powerful, they are also easy to misuse.

Why It's a Problem

Access keys are long-lived credentials. If they are exposed through source code repositories, configuration files, logs, or shared scripts, an attacker can use them immediately, often without triggering obvious alarms.

Unlike passwords, access keys do not expire by default and are frequently forgotten after being created.

Once compromised, access keys can be used from anywhere in the world to interact with AWS APIs, potentially allowing attackers to read data, launch resources, or incur significant costs.

How to Avoid It

Use IAM roles instead of access keys whenever possible
Store secrets in AWS Secrets Manager or Parameter Store (Secure String)
Rotate access keys regularly and delete unused ones
Monitor access key usage with CloudTrail

Access keys should be treated like highly sensitive secrets. In most modern AWS environments, they should be the exception, not the default.

7. Overly Permissive IAM Policies

Beginners often use policies like AdministratorAccess or *:* just to make things work.

Why It’s a Problem

Violates the principle of least privilege
Increases blast radius if credentials are compromised
Makes auditing difficult

How to Avoid It

Start with minimal permissions
Grant only what is required
Use AWS-managed policies as learning references, not defaults

Convenience today becomes risk tomorrow.

8. Logging and Monitoring Gaps

If you don’t log activity, you won’t know when something goes wrong.

Why It’s a Problem

Without logs, you cannot:

Detect suspicious behavior
Investigate incidents
Prove compliance

How to Avoid It

Enable AWS CloudTrail
In large organizations with multiple AWS accounts, configure an organization trail in CloudTrail
Protect CloudTrail so that only the security team can change settings
Send logs to a protected S3 bucket
Monitor alerts using CloudWatch, Security Hub or a third-party solution

Visibility is a core security requirement, not an optional feature.

9. Insecure use and storage of Secrets and Access Keys

Hard-coding passwords and API keys is a common beginner shortcut. Similarly, secrets that never change are secrets that eventually get compromised.

One of the most common security oversights in AWS environments is creating credentials: passwords, access keys, or secrets, and then leaving them unchanged for months or even years.

Why It’s a Problem

Credentials can leak via source control
They are hard to rotate
They are often shared unintentionally

How to Avoid It

Use AWS Secrets Manager or Parameter Store for secrets
Use IAM roles instead of access keys and IAM users
Rotate credentials frequently.

10. No encryption of stored data

Failing to encrypt data at rest is a common security gap in AWS environments, particularly in early-stage or test accounts where security controls are often overlooked.

While AWS supports encryption for most storage services, it is not always enabled automatically or consistently across all resources.

Why It's a Problem

Unencrypted data is vulnerable if storage is accessed by unauthorized users, compromised credentials, or misconfigured permissions.

Without encryption, anyone who gains access to the underlying data can read it directly, including sensitive customer information, credentials, backups, or intellectual property.

Encryption adds a critical layer of protection by ensuring that even if data is accessed improperly, it cannot be read without the appropriate encryption keys.

How to Avoid It

For S3 buckets, encryption at rest is enabled by default but consider using your own encryption key
Enforce encryption in transit when interacting with S3 buckets
Require encryption for EBS volumes and snapshots
Use AWS Key Management Service (KMS) to manage encryption keys
Enforce encryption using AWS Config rules or service control policies (SCPs)

Security Groups vs Network ACLs: The Two Firewalls You Didn’t Know You Were Using in AWS

Nicolás — Sat, 03 Jan 2026 11:55:33 +0000

Firewalls are essential for deciding what traffic is allowed in or out of a network. In traditional, on-prem networks, controlling traffic is usually straighforward, not because the configuration is simple, but because the structure is (hopefully) well undestood.

You know how the network is laid out, what connects to what, and what should be talking with what. In other words, you (hopefully) know the internal details.

Security teams are used to thinking in terms of:

A single firewall (or a small number of them)
Clearly defined network edges
Rules applied at obvious choke points

When moving to the cloud, this mental model no longer fully applies, although the concept of firewall still exist, it appears under a different name.

Firewalls in AWS

AWS does not have a single perimeter firewall protecting your environment. Instead, traffic control is distributed across multiple layers and services. Security decisions are no longer made in just one place, but at different points within the network, sometimes at the subnet level, sometimes at the resource level.

This shift in approach is often one of the biggest challenges for people new to AWS. The tools are different, the terminology is new, and familiar concepts do not always behave the same way.

Networking basics

Before discussing how we can control traffic in AWS, it is important to understand a few core networking constructs that everything else builds upon.

VPC (Virtual Private Cloud)

A VPC is a logically isolated network within AWS. You can think of it as your own private data center network in the cloud.

Within a VPC, you define:

The IP address range (CIDR block)
Subnets
Routing rules
Network security controls

By default, resources inside a VPC cannot be accessed from the internet unless you explicitly allow it.

This gives you full control over how traffic flows into, out of, and within your environment.

Subnet

A subnet is a subdivision of a VPC’s IP address range. Each subnet exists within a single AWS Availability Zone and represents a smaller network segment.

Subnets are commonly used to separate workloads based on purpose or exposure, for example:

Public subnets (internet-facing resources)
Private subnets (internal services, databases)

Controlling network traffic

Two of the most important network security controls in AWS are Security Groups and Network ACLs. Both act like firewalls, but they operate at different layers and follow different rules.

Security Groups: protect individual resources (like EC2 instances)
Network ACLs: protect entire subnets

Let's look at the following figure to understand it better:

Traffic flows from the internet into AWS, but before it can reach your application, it must first stop at the subnet level, where a Network ACL verifies whether the traffic is allowed. If it is, the traffic continues and stops at the doorway of your application. There, a gatekeeper performs a second verification check to ensure the traffic is allowed to reach the application.

As you can see, both controls work in combination to protect your workloads, as traffic can be dropped at either layer if the checks are unsuccessful.

Let’s examine them in more detail.

Network ACL

A Network ACL (NACL) acts like a security gate at the entrance of a building. It controls:

What traffic can enter a subnet
What traffic can leave a subnet

NACLs are applied at the subnet level and are free of charge. Every subnet must be associated with a NACL. If none is specified, the subnet is associated with the default NACL, which allows all inbound and outbound traffic. A subnet can only be associated with one NACL.

NACLs are composed of rules that control traffic. Each rule can either allow or deny traffic, and rules are evaluated in order based on a number you assign to each rule. Evaluation starts with the lowest number and continues until the traffic matches a rule.

A key concept of NACLs is that they are stateless, meaning inbound and outbound connections are treated separately. This means that both inbound and outbound rules must explicitly allow traffic for a connection to be successful.

You must think about both directions:

Inbound traffic must be explicitly allowed
Outbound traffic must also be explicitly allowed

Let's look at an example.

Imagine that you have a subnet where you host a public web server meant to be accessed from anywhere in the world by anyone.

You need both HTTP (unencrypted, not recommended) and HTTPS traffic to reach your application.

In this situation, your Inbound rules might look like this:

100 ALLOW HTTP (80) 0.0.0.0/0
110 ALLOW HTTPS (443) 0.0.0.0/0
DENY ALL

Because NACLs, are stateless, we need to have rules allowing the outbound connectivity:

100 ALLOW ALL 0.0.0.0/0
DENY ALL

Security Groups

A security group is associated with a resource and controls the traffic that reaches it and leaves it. In other words, it controls inbound and outbound traffic to and from the resource.

Similar to NACLs, security groups are composed of rules that control both inbound and outbound traffic. The components of these rules are:

the source (i.e. IP address, IP range)
port range (i.e. 22, 80, 25-30)
protocol (TCP, UDP, ICMP)

Unlike NACLs, which support both ALLOW and DENY rules, security groups only support ALLOW rules. Another difference is that you can attach multiple security groups to a single resource.

However, the most important difference between NACLs and security groups is that security groups are stateful. This means they keep track of allowed connections. If inbound traffic is allowed, the corresponding return traffic is automatically allowed.

You only need to think about the initial request.

You do not need to explicitly allow response traffic.

Continuing with the web server example, the traffic has passed the NACL and is now attempting to reach your application.

You create a security group with the following rules:

Allow inbound HTTP (port 80) from anywhere (0.0.0.0/0)
Allow inbound HTTPS (port 443) from anywhere (0.0.0.0/0)

If a user sends a request on port 80 or 443, the Security Group allows it, and the response is automatically allowed back.

You do not need to add a rule for return traffic.

This is what “stateful” means.

Comparison

When to use them

Both Network ACLs and Security Groups act as firewalls, and are typically used together rather than as alternatives. You can think of them as different security layers protecting your resources.

Ideally, you should configure both of them appropriately to ensure that only expected traffic reaches your application.

When to Use Security Groups

Security Groups should be your primary mechanism for controlling traffic in AWS and you want:

Fine-grained control at the resource level (EC2, ALB, RDS, etc.)
Simple, intuitive rules that follow the application logic
Automatic handling of return traffic (stateful behavior)
Micro-segmentation between tiers (web, application, database)

In practice, most application level access decisions, such as which services can talk to each other, are enforced using Security Groups.

When to Use Network ACLs

Use Network ACLs when you need:

A broad security boundary at the subnet level
An additional layer of protection to block or restrict traffic
Explicit deny rules (which Security Groups do not support)
Guardrails that apply to all resources within a subnet

NACLs are often used as a secondary control to enforce high-level policies, such as blocking known malicious IP ranges or preventing unintended exposure.

AWS Shared Responsibility Model Explained

Nicolás — Tue, 30 Dec 2025 10:42:08 +0000

One of the most dangerous assumptions when starting to work with cloud environments is believing that workloads are secure by default. After all, if you are using the cloud, the provider should take care of security, right?

Not exactly.

Cloud providers are responsible for security, but only to a certain extent.

Imagine checking into a hotel and booking a room. The hotel is responsible for maintaining the building, hiring security staff, and monitoring cameras to secure entrances and hallways. It provides locks on the doors, installs smoke detectors and sprinklers, ensures that electricity and water work, and even offers a safe in each room for guests’ valuables.

In other words, the hotel is responsible for keeping the hotel itself secure.

You, the guest, are still responsible for locking your room when you leave. You decide who is allowed to enter, and you choose whether or not to use the safe to protect your valuables.

The hotel gives you a lock, but you must actually use it.

The same concept applies in the cloud. Cloud providers ensure that the underlying cloud infrastructure is secure, but you are responsible for securing your workloads and protecting your environment.

This division of responsibility, in the context of AWS, is known as the Shared Responsibility Model, and it is exactly what we are going to explore in this post.

What is the AWS Shared Responsibility Model?

The AWS Shared Responsibility Model defines how security responsibilities are divided between:

AWS (the cloud provider) is responsible for security of the cloud
You (the customer) are responsible for security in the cloud

This concept is best illustrated by [AWS] itself:(https://aws.amazon.com/es/compliance/shared-responsibility-model/)

AWS Responsibility

AWS is responsible for protecting the infrastructure that runs all AWS services. This includes:

Physical data centers (buildings, locks, guards, cameras)
Hardware (servers, storage devices, networking equipment)
Global infrastructure (regions and availability zones)
Core services infrastructure (compute, storage, networking foundations)
Hypervisors and underlying virtualization layers

For example, if a physical server in an AWS data center fails or is physically tampered with, AWS is responsible for detecting and resolving that issue. Customers never manage or even see this hardware, and as such, they don't need to worry about:

Data center access control
Physical server patching
Power, cooling, or hardware lifecycle

AWS handles all of it.

Customer responsiblity

As a customer, you are responsible for how you configure and use AWS services, which includes:

IAM users, roles, and permissions
Operating systems (for EC2)
Network configurations (VPCs, security groups, NACLs)
Data encryption and key management
Application security
Logging and monitoring
Compliance with your own regulatory requirements

Let's look at an example to better understand this.

Imagine your marketing team stores images of an unreleased product in a private S3 bucket. The images are protected from the outside world because the bucket has strict access controls. However, a mistake occurs and the S3 bucket is made public temporarily, but long enough for someone to access and download the images.

Even though the bucket is hosted on AWS infrastructure, this incident is your responsibility, because you control and manage the security configuration of that bucket.

Real Examples

Amazon EC2 (Virtual Servers)

With EC2, you have significant control and responsibility.

AWS handles:

Physical servers
Hypervisor
Data center security

You handle:

OS patching (Linux/Windows updates)
Firewall rules (security groups)
SSH/RDP access
Installed software vulnerabilities
Application-level security

Common mistake:
Assuming AWS patches your EC2 operating system automatically. AWS does not.

Amazon S3 (Object Storage)

S3 is fully managed, but configuration is your responsibility.

AWS handles:

Storage infrastructure
Durability and availability
Physical protection of disks

You handle:

Bucket access policies
Public vs private access
Encryption settings
Who can read or write data

Common mistake:
Leaving buckets publicly accessible because “AWS would block that if it was unsafe.”

AWS Lambda (Serverless)

As services become more managed, your responsibilities decrease, but never disappear.

AWS handles:

Servers and OS
Runtime environment
Scaling and availability

You handle:

IAM permissions for the function
Secure handling of secrets
Application logic
Data access controls

Why This Model Matters for Security

There is a common misconception that security incidents in AWS are caused primarily by sophisticated attacks, but that could not be farther from the truth.

In reality, most incidents in AWS stem from customer-side errors, such as misconfigurations, weak identity controls, and insufficient monitoring. This is consistently highlighted in industry research, including Tenable 2025 Cloud Security Risk Report and Top Threats to Cloud Computing 2024 report published by the Cloud Security Alliance (CSA)

Because of this, it is critical to understand what falls under your responsibility so you can apply the appropriate security controls and guardrails to prevent issues such as:

Public data exposure
Overly permissive IAM roles
Data tampering
Unpatched systems
Missing logs and alerts

Final Thoughts

AWS provides a highly secure cloud platform, but security is a shared effort. AWS secures the foundation; you secure everything built on top of it.

WhatsApp Ghost Pairing: A Silent Abuse of Linked Devices

Nicolás — Tue, 23 Dec 2025 16:00:00 +0000

In the previous blog, we discussed how to detect if your WhatsApp account has been compromised and the safeguards you can adopt to protect your account against common cyber threats.

Today, I’m going to show you a specific attack that aims to monitor and spy on your conversations without your awareness. This technique is called Ghost Pairing.

What is Ghost Pairing?

Ghost Pairing is an attack vector in which an attacker secretly links their own device to your WhatsApp account using the official Linked Devices feature. Their intention is not to fully take over your account but to let you continue using it normally while they:

Read all messages you send and receive
Access your photos, videos, and documents
Impersonate you by sending messages to your contacts

Sounds scary, right?

How Ghost Pairing Works

WhatsApp allows one account to be linked to up to four devices. Ghost pairing abuses this design. The attack does not target WhatsApp’s encryption or internal security. Instead, it targets the user, exploiting human behavior to grant unauthorized access.

There are two common scenarios in which this attack can occur:

Physical Access

If you leave your phone unlocked and unattended, an attacker can take advantage of that moment to link your WhatsApp account to their own device.

No verification SMS is sent

You are not logged out of your account

The attacker can dismiss the push notification WhatsApp sends for new linked devices

Remote access

In this scenario, the attacker gains access without physically handling your phone. This usually involves social engineering techniques designed to trick you into revealing information:

The attacker convinces you to share the WhatsApp verification code you received via SMS. (Reminder: never share this code with anyone.)
The attacker impersonates one of your contacts and attempts to trick you into providing the verification code or visiting a malicious link
You visit a seemingly innocent website that claims you must verify your phone to view content, but in the background it collects your verification code

Why It’s Dangerous

Ghost pairing is especially risky because:

No obvious takeover – your account still works
Real-time spying – messages sync instantly
Persistent access – stays active until manually removed
Perfect for scams – attackers can impersonate you
No advanced skills needed - attackers simply exploits an official WhatsApp feature

Common Signs of Ghost Pairing

Be alert for these warning signs:

A linked device you don’t recognize under Settings → Linked Devices
Messages marked as “read” when you didn’t open them
Contacts receiving messages you don’t remember sending
Unusual activity times in Last Seen

How to Protect Yourself

The good news is ghost pairing is easy to prevent if you follow basic security practices:

Lock your phone (PIN, biometrics, auto-lock) and don't leave it unattanded
Regularly check Linked Devices and remove any unfamiliar ones
Enable notifications for new linked devices
Enable two-step verification (2FA) for your WhatsApp account

If you found this article helpful, share it with your friends and family to help them stay informed and protected. Remember: security is everyone’s responsibility.

How to Tell If Your WhatsApp Account Is Hacked — and How to Protect Yourself

Nicolás — Mon, 22 Dec 2025 13:50:08 +0000

WhatsApp is the most widely used instant messaging platform on the planet, with over 3.5 billion active accounts in 2025. For many people, it has become the de facto channel for personal communication, and small businesses and even larger corporations have also adopted it as an easy way to communicate with customers.

WhatsApp’s global reach and its importance in people’s daily lives make it a high-value target for cybercriminals. For this reason, it’s essential to understand how to protect yourself and recognize the warning signs that your account may be at risk.

Recognizing the Signs Your WhatsApp Account May Be Compromised

Unexpected Activity

Messages are marked as read without your involvement.
Messages or media you didn’t send appear in your chats.
New contacts or group chats appear that you don’t recognize or didn’t add.
Your Last Seen status shows activity at times when you weren’t using the app.

Unknown Linked Devices

Linked Devices is a feature that allows you to securely access your WhatsApp account from multiple devices (such as WhatsApp Web, desktop apps, or another phone). These linked devices have full access to your chats and media, meaning they can read your messages, view your photos, and send messages to your contacts.

For this reason, it’s important to periodically review your list of linked devices and immediately remove any that you don’t recognize.

Changes to Profile Information

If your profile photo, status, or display name changes without your consent, it’s a strong indication that someone else may have access to your account.

You Receive Unexpected Verification Codes

If you receive an SMS containing a WhatsApp verification code that you did not request, it likely means someone is attempting to register your phone number on another device.

DO NOT SHARE THIS CODE WITH ANYONE. Sharing it would give them full access to your account.

You Can’t Log In or Have Been Logged Out

If WhatsApp reports that your number is “no longer registered” on your device, or if you are suddenly logged out and unable to sign back in using your phone number, your account may have been compromised.

What to Do If You Suspect Your Account Is Comrpomised

Once you identify suspicious activity, take the following steps immediately.

Step 1: Regain Control

Open WhatsApp and sign in using your phone number.

Enter the six-digit verification code sent via SMS. This will automatically log out any existing sessions on devices controlled by an attacker.

If you’re unable to receive the six-digit code because the attacker has enabled or changed two-step verification, WhatsApp typically enforces a waiting period (for example, seven days) before you can register the number again without the two-step verification PIN.

Step 2: Log Out Unknown Devices

If you still have access to your account, go to Settings → Linked Devices.

Review the list and log out of any devices you don’t recognize.

Step 3: Alert Your Contacts

Notify friends, family, and colleagues that your account may have been compromised so they do not fall for scams sent from your profile.

Practical Tips to Protect Your WhatsApp Account

Enable Two-Step Verification (2FA)

Even though two-step verification is an optional security feature, it's highly recommended enabling it as it significantly strengthens your account by adding a six-digit PIN required to register your number on a new device.

It is the single most effective defensive measure you can enable.

To enable it, go to:

Settings → Account → Two-step verification → Enable.

Then:

Enter a six-digit PIN
Add an email address to help you recover your PIN if you forget it

Never Share Your Verification Codes

WhatsApp will never ask you for your SMS verification code or your two-step verification PIN. Sharing either of these, even with someone claiming to be WhatsApp support, almost always results in account takeover.

Monitor Linked Devices Regularly

Periodically review the list of devices linked to your WhatsApp account and log out of any sessions you don’t recognize.

Go to Settings → Linked Devices to see the full list.

Use Strong Device Security

Protect your phone with a secure PIN, biometric lock, or strong password. This reduces the risk of someone accessing your WhatsApp account if your device is lost or stolen.

Also, make sure your phone is locked when you leave it unattended. Anyone with access to an unlocked phone could link their own device to your WhatsApp account and monitor your conversations.

Be Wary of Links, Files, and Phishing Attempts

Attackers often send malicious links or files designed to install malware or trick you into revealing sensitive information. Avoid clicking unknown links, opening suspicious attachments, or installing apps from unofficial sources.

Update WhatsApp and Your Operating System

Security updates frequently patch vulnerabilities that attackers exploit. Enable automatic updates for WhatsApp and your device’s operating system.

Enable Push Notifications on your phone

WhatsApp sends a notification whenever a new device is linked to your account. Keeping notifications enabled allows you to quickly detect and remove unauthorized devices.

Avoid Unofficial Apps and Tools

Linked Devices is a feature officially provided by WhatsApp at no cost. Using unofficial or third-party apps to link your account can expose your messages and credentials, putting your account at serious risk.

Final Thoughts

WhatsApp is widely regarded as a secure platform thanks to its end-to-end encryption. However, account takeovers remain common because attackers typically exploit human behavior through social engineering rather than breaking cryptographic protections.

By recognizing the warning signs of compromise and adopting strong account security practices, especially enabling two-step verification and carefully handling verification codes and links, you can significantly reduce your risk and better protect your communications.

When a seemingly innoffensive conversation with AI turns malicious

Nicolás — Tue, 16 Dec 2025 21:15:47 +0000

AI has changed the way we interact with technology in many ways, from simple tasks such as generating text and helping with homework to more technical ones like creating web pages and assisting developers with code reviews.

One of the most significant changes has been the way we search for information. It is now common to default to an LLM such as ChatGPT, Gemini, Grok, or Claude to ask about almost anything we can think of: planning trips, searching for historical facts, explaining complex documentation, or helping us fix problems by providing step-by-step guides.

It is in this last area where cybercriminals have found a way to exploit the trust users place in these platforms, creating an attack vector that tricks users into downloading and installing malware designed to steal credentials, as reported earlier this month by the cybersecurity company Huntress.

What category does this attack fit into?

Social engineering through the “impersonation” of a legitimate LLM conversation.

How does it work?

I will leave out the technical details for the sake of simplicity and refer you to the original article. In a nutshell, the attack abuses the shareable conversation feature available in
Grok and OpenAI.

This feature allows users to generate a unique URL that can be easily shared on social media, instant messaging platforms, or public forums, and anyone with the link can access the conversation.

These conversations can be indexed by search engines and may rank highly in search results, causing them to appear at the top of the page and point to a seemingly legitimate conversation.

Why does it work?

The conversations resemble step-by-step guides on how to perform common operations on macOS devices, such as clearing storage.

Users access the link through a browser and see a real conversation with an LLM—real in the sense that it is the actual UI and platform used when interacting with Grok or ChatGPT.

This creates an element of trust, as users are familiar with these platforms. However, without realizing it, the steps include malicious terminal commands that open the user’s computer to attackers.

How to protect yourself

AI is not flawless. We all know that LLMs can hallucinate and provide made-up information in an attempt to be helpful. In that sense, this scenario is not entirely different. If an LLM were to ask for your Social Security number, your bank password, or guide you through making a bank transfer to an account number you don't know, you would not do it, right?

Here, instead of asking for sensitive information directly, the model instructs users to run commands in their device’s terminal without clearly explaining what those commands do - and those commands can be highly destructive.

The recommended precautions

Never provide sensitive information.
Never execute terminal commands unless you fully understand what they do, even if they appear to come from a trusted source.
Follow good password hygiene to keep your accounts secure, such as never reusing passwords and using a password manager to generate strong, unique credentials.

Beware the Forgotten Tab: Understanding and Preventing Tabsnabbing

Nicolás — Sun, 09 Nov 2025 09:18:56 +0000

If you’re anything like me, your curiosity tends to get the better of you. You start reading a blog post, click on a related article (or two… or ten), and before you know it, your browser looks like a chaotic battlefield of open tabs.

This kind of tab-hopping often comes from our multitasking instincts — reading a bit here, jumping there, chasing the next interesting thing that catches our eye. Before long, you’ve gone so far down the rabbit hole that you’re learning how nut prices in Asia affect global trade, even though all you wanted to know in the first place was whether it’s going to be sunny tomorrow.

Now, having too many tabs open isn’t really a problem — at least, not if your computer can handle it. But what if I told you that, somewhere in that ocean of forgotten tabs, something darker might be waiting? Something that could turn against you the moment you let your guard down?

Welcome, my friend, to Tabsnabbing — a sneaky phishing technique that exploits your trust in your own open tabs.

What Is Tabsnabbing?

Tabsnabbing is a type of phishing attack that leverages inactive browser tabs. When a user navigates away from a page but leaves its tab open, a malicious site can detect that state and replace its content with a realistic-looking login page (for example Gmail, GitHub, or an online bank). If the user returns and enters their credentials, the attacker captures them.

Tabsnabbing Types

There exist two types of tabsnabbing:

Passive (the most common)
This is the one that changes the original content of the website, when the tab is inactive, for a login page. When you return to it, it gives the impression that the session expired, so the user is more likely to enter their credentials.
Reverse
This one occurs when you click on a link that opens a new browser tab. Unknowingly, this action triggers a process that automatically change the content of previous page.

Why It Works So Well

Tabsnabbing preys on two simple things:

Trust
You think the tab is still the site you opened earlier (e.g., “That’s my Gmail tab, right?”).
Distraction
We multitask. We leave tabs open for hours. Sometimes days.

The combination means that when you return to a tab and see a login page, your brain fills in the blanks: “I must’ve been logged out.” And that’s when the attacker wins.

What Risks We Face

Identity Theft
Attackers can pretend they are you if they manage to your credentials for email account, your social accounts (TikTok, Instagram, Facebook...)
Financial Loss
Capturing your bank credentials can lead to attackers transfering money out your account, using your card details to purchase goods
Access to sensitive information
Company's proprietary data if your work credentials are captured, your medical records...

How to Protect Yourself

Close tabs you are not using
Verify the URL before entering credentials. If in doubt, close the tab and navigate to the login page.
Don't reuse passwords
Enable MFA whenever possible

Final Thoughts

Tabsnabbing is one of those web security gotchas that’s easy to underestimate. It doesn’t rely on zero-days or fancy exploits — just our everyday browsing habits.

It’s a good reminder that security is as much about psychology as it is about code.

DEV Community: Nicolás

Do you know the difference between Terraform Provider and Module?

Providers - The translator layer

The Terraform Registry

Using Providers

Modules - Reusability is served

Using modules

Conclusion

How to prevent member accounts from leaving your AWS organization

Do you pin your base images in Dockerfile?

TL;DR

Intro

So what is the Dockerfile?

The Base Image

The Problem with Selecting Versions

Always Pin the Image

Terraform - How to prevent sensitive data from ending up in the .tfstate

TL;DR

Intro

What Does the Documentation Say?

Scenario 1: Hardcoded Secret

Scenario 2: The sensitive argument to the rescue (or almost)

Scenario 3: Secrets in an external platform

Scenario 4: Using ephemeral for the win

Conclusions

Basic protections for your S3 buckets

Encryption

Encryption at rest

Encryption in transit

Public/Private buckets

Least privilege

Versioning & MFA delete

Top 10 AWS Security Mistakes Beginners Must Avoid

1. Using the Root Account for Daily Work

2. Not Enabling Multi-Factor Authentication (MFA)

3. Having public S3 buckets

4. Overly permissive Security Groups

5. Insufficient Password Policies

6. Insecure Use of Access Keys

7. Overly Permissive IAM Policies

8. Logging and Monitoring Gaps

9. Insecure use and storage of Secrets and Access Keys

10. No encryption of stored data

Security Groups vs Network ACLs: The Two Firewalls You Didn’t Know You Were Using in AWS

Firewalls in AWS

Networking basics

VPC (Virtual Private Cloud)

Subnet

Controlling network traffic

Network ACL

Security Groups

Comparison

When to use them

When to Use Security Groups

When to Use Network ACLs

AWS Shared Responsibility Model Explained

What is the AWS Shared Responsibility Model?

AWS Responsibility

Customer responsiblity

Real Examples

Why This Model Matters for Security

Final Thoughts

WhatsApp Ghost Pairing: A Silent Abuse of Linked Devices

What is Ghost Pairing?

How Ghost Pairing Works

Why It’s Dangerous

Common Signs of Ghost Pairing

How to Protect Yourself

How to Tell If Your WhatsApp Account Is Hacked — and How to Protect Yourself

Recognizing the Signs Your WhatsApp Account May Be Compromised

What to Do If You Suspect Your Account Is Comrpomised

Practical Tips to Protect Your WhatsApp Account

Final Thoughts

When a seemingly innoffensive conversation with AI turns malicious

What category does this attack fit into?

How does it work?

Why does it work?

How to protect yourself

The recommended precautions

Beware the Forgotten Tab: Understanding and Preventing Tabsnabbing

Scenario 2: The `sensitive` argument to the rescue (or almost)

Scenario 4: Using `ephemeral` for the win