Forem: Yasir Nawaz

ESP32 WiFi Security Explained for Beginners

Yasir Nawaz — Sun, 11 Jan 2026 13:47:29 +0000

ESP32 is one of the most popular microcontrollers in the IoT world, mainly because it combines strong processing power with built-in WiFi and Bluetooth at a very affordable cost. Beginners often focus on getting WiFi connectivity working as quickly as possible, but security is usually ignored in early projects. Unfortunately, insecure ESP32 devices are easy targets for attackers and can lead to data leaks, unauthorized control, or even large-scale botnet abuse.

This blog is a beginner-friendly yet deep dive into ESP32 WiFi security. We will cover how WiFi communication works on ESP32, common attack vectors, firmware security basics, encryption, secure OTA updates, and practical steps you can apply today. Even if you are new to embedded systems, this guide will help you build safer ESP32-based IoT devices.

Why ESP32 WiFi Security Matters

Every ESP32 connected to WiFi becomes part of a network. That network could be your home, your office, or a production environment. Once connected to the internet, your device is exposed to:

Unauthorized access attempts
Packet sniffing
Man in the middle attacks
Firmware tampering
Credential theft
Remote command injection

Many real-world IoT attacks happened not because the hardware was weak, but because security was never enabled. ESP32 actually provides strong security features, but they must be configured correctly.

How ESP32 Connects to WiFi (Beginner Overview)

Before securing WiFi, it is important to understand how the ESP32 connects.

Basic WiFi flow:

ESP32 scans for available networks
It authenticates using the SSID and password
It obtains an IP address via DHCP
It starts sending and receiving data

A simple ESP-IDF example looks like this:

wifi_config_t wifi_config = {
    .sta = {
        .ssid = "MyWiFi",
        .password = "mypassword",
    },
};

esp_wifi_set_mode(WIFI_MODE_STA);
esp_wifi_set_config(WIFI_IF_STA, &wifi_config);
esp_wifi_start();

This works, but it is not secure by default.

Common WiFi Security Mistakes Beginners Make

Understanding mistakes helps you avoid them.

1. Hardcoding WiFi Credentials

Hardcoding the SSID and password in the firmware makes extraction easy if someone reads the flash.

2. Using Open or Weak WiFi Networks

Open networks or WEP based networks offer almost no protection.

3. No Encryption for Data Transfer

Sending data over HTTP instead of HTTPS exposes it to sniffing.

4. Disabling Certificate Verification

Many beginners disable TLS verification to fix connection errors, which defeats security entirely.

5. No OTA Security

Unsigned OTA updates allow attackers to install malicious firmware.

WiFi Network Security Basics for ESP32

Use WPA2 or WPA3 Only

Always connect ESP32 devices to networks secured with WPA2 or WPA3. Avoid open networks in production environments.

Avoid Reusing WiFi Credentials

If possible, use device provisioning instead of embedding credentials permanently.

Secure WiFi Provisioning

Better provisioning methods include:

BLE based provisioning
Temporary Access Point with one-time password
QR code-based provisioning

ESP-IDF provides a secure WiFi provisioning framework that encrypts credentials during setup.

Official documentation: docs.espressif.com

Securing ESP32 Firmware Basics

WiFi security is useless if the firmware itself is compromised.

Secure Boot

Secure Boot ensures only trusted firmware runs on the device. The ESP32 verifies the firmware signature during startup.

Benefits:

Prevents malicious firmware injection
Stops unauthorized firmware modification

ESP-IDF Secure Boot docs: docs.espressif.com

Flash Encryption and WiFi Credentials Protection

ESP32 stores WiFi credentials in flash memory. Without flash encryption, anyone with physical access can extract them.

What Flash Encryption Does

Encrypts firmware stored in flash
Encrypts WiFi credentials
Protects API keys and tokens

Once enabled, flash contents are unreadable outside the ESP32.

Flash encryption docs: docs.espressif.com

Secure Communication Over WiFi

Always Use TLS

All data sent over WiFi should be encrypted using TLS.

Protocols to use:

HTTPS instead of HTTP
MQTT over TLS instead of plain MQTT

Example HTTPS request using ESP-IDF:

esp_http_client_config_t config = {
    .url = "https://api.example.com/data",
    .cert_pem = server_cert_pem,
};

esp_http_client_handle_t client = esp_http_client_init(&config);
esp_http_client_perform(client);

Certificate Validation Is Mandatory

Never disable certificate verification. If memory is limited, use:

Certificate pinning
ECC certificates instead of RSA

Device Identity and Authentication

Every ESP32 device must be uniquely identifiable.

Bad Practice

One API key shared across all devices

Good Practice

Unique device ID
Per device token
Certificates per device

This prevents one compromised device from affecting others.

OTA Updates and WiFi Security

OTA updates are powerful and dangerous.

Secure OTA Checklist

Use HTTPS for OTA download
Verify firmware signature
Enable rollback protection
Reject unsigned firmware

ESP-IDF OTA security guide: docs.espressif.com

OTA without signature verification is one of the biggest IoT security risks.

Common ESP32 WiFi Attack Vectors

Man in the Middle Attack

Occurs when data is intercepted between the ESP32 and the server. Prevented by proper TLS validation.

Evil Twin WiFi Attack

The attacker creates a fake WiFi network with the same SSID. Mitigated by WPA2 and certificate validation.

Firmware Extraction

Prevented by flash encryption and disabling debug interfaces.

Replay Attacks

Prevented using timestamps, nonces, and server-side validation.

Logging and Debugging Without Leaking Data

Avoid printing sensitive data in logs.

Never log:

WiFi passwords
Tokens
Certificates

Disable verbose logging in production builds.

Beginner Friendly Security Checklist

Before deploying an ESP32 device:

Use WPA2 or WPA3 WiFi
Enable Secure Boot
Enable Flash Encryption
Use HTTPS or MQTT over TLS
Validate certificates
Secure OTA updates
Disable debug interfaces
Use a unique device identity

FAQs (Frequently Asked Questions)

Is ESP32 secure enough for commercial products?

Yes, if Secure Boot, flash encryption, and TLS are properly enabled. Many commercial IoT products use ESP32.

Can WiFi passwords be extracted from ESP32?

Yes, if flash encryption is disabled. With flash encryption enabled, extraction becomes extremely difficult.

Is HTTPS heavy for ESP32?

HTTPS consumes more memory, but ESP32 hardware acceleration and ECC certificates make it practical for most use cases.

Should beginners enable Secure Boot?

Yes. It is better to learn with security enabled than to add it later.

Is MQTT secure on ESP32?

MQTT itself is not secure, but MQTT over TLS is secure and widely used in IoT.

Can OTA updates be hacked?

Yes, if firmware signatures are not verified. Secure OTA prevents this.

Conclusion

ESP32 WiFi security is not optional anymore. Even beginner projects can become real-world targets once connected to the internet. The good news is that ESP32 provides excellent security features out of the box. By understanding WiFi communication, enabling encryption, securing firmware, and using proper OTA practices, you can build IoT devices that are resilient and trustworthy.

Start with small steps. Enable TLS, protect credentials, and avoid shortcuts. Over time, security will become a natural part of your ESP32 development workflow.

Author: Yasir Nawaz

Embedded Systems and Cyber Security Engineer

Resume:

View my professional resume at sudoyasir.space

Email:

y451rmahar@gmail.com

LinkedIn:

/in/sudoyasir

GitHub:

github.com/sudoyasir

If you found this article helpful, connect with me on LinkedIn or explore my open source projects on GitHub for more ESP32, IoT security, Linux, and embedded systems content.

Complete ESP32 Security Guide for IoT Devices

Yasir Nawaz — Sat, 10 Jan 2026 14:37:49 +0000

The ESP32 has become one of the most popular microcontrollers for IoT projects. It is powerful, affordable, and packed with features like WiFi, Bluetooth, dual cores, and hardware accelerators. These same features that make ESP32 attractive also make it a common target for attacks. Many IoT devices built on ESP32 end up deployed in homes, offices, factories, and public spaces, often connected to the internet 24/7.

Security is not optional anymore. A single vulnerable device can be used to spy on users, leak sensitive data, or become part of a botnet. This guide is written as a practical, end-to-end security reference for ESP32 based IoT devices, covering hardware, firmware, communication, cloud integration, and lifecycle security.

1. Understanding the ESP32 Security Model

ESP32 includes several built-in security features at the silicon level. Many developers never enable them, either due to a lack of awareness or fear of complexity. Understanding these features is the first step.

Key security capabilities of ESP32 include:

Secure Boot (v1 and v2)
Flash Encryption
Hardware RNG
AES, SHA, RSA, ECC accelerators
eFuses for permanent configuration
Memory protection features
Secure key storage

These features work together to ensure that only trusted firmware runs on the device, sensitive data remains encrypted, and cryptographic operations are efficient and safe.

2. Threat Model for ESP32 IoT Devices

Before implementing security, you must understand what you are protecting against. Common threats include:

Physical access to the device
Firmware extraction via UART or SPI flash
Malicious OTA updates
Man-in-the-middle attacks on WiFi
Credential leakage from firmware
Cloud API abuse
Replay attacks on device commands
Device cloning

A good security design assumes that attackers may have temporary physical access and full network visibility.

3. Secure Boot on ESP32

Secure Boot ensures that only firmware signed by you can run on the device. If an attacker modifies the firmware, the device will refuse to boot.

Secure Boot v1 vs v2

Secure Boot v1 uses RSA-based signature verification.
Secure Boot v2 improves key management and supports stronger algorithms.

For new projects, always use Secure Boot v2.

How Secure Boot Works

A public key hash is burned into eFuse.
Firmware images are signed with the private key.
At boot, the ROM bootloader verifies the firmware signature.
If verification fails, the boot is halted.

Best Practices

Generate keys offline on a secure machine.
Never store private keys in your source repository.
Enable Secure Boot early in development.
Lock eFuses once testing is complete.

4. Flash Encryption

Flash encryption protects firmware and data stored in external flash. Without it, anyone with physical access can read firmware and secrets.

What Flash Encryption Protects

Application firmware
WiFi credentials
API tokens
Certificates
Custom data stored in flash

How It Works

ESP32 uses AES-XTS encryption. A flash encryption key is stored securely in eFuse. All reads and writes to flash are transparently encrypted and decrypted by hardware.

Development vs Release Mode

Development mode allows reflashing.
Release mode permanently locks encryption.

Always move to release mode before mass production.

5. eFuse Management and Strategy

eFuses are one-time programmable bits inside ESP32. They control critical security features.

Important eFuse uses:

Secure Boot key hash
Flash encryption key
Disabling JTAG
Disabling UART download mode
Configuring debug access

Best Practices

Plan your eFuse usage before production.
Document which eFuses are burned at each stage.
Use scripts to ensure consistent programming.
Avoid manual burning in production lines.

Once burned, eFuses cannot be undone.

6. Protecting Debug Interfaces

UART, JTAG, and other debug interfaces are useful during development but dangerous in production.

Recommendations

Disable JTAG via eFuse.
Disable UART bootloader if OTA is used.
Require authentication for any debug interface.
Use custom bootloader logic if needed.

Leaving debug ports open is one of the most common ESP32 security mistakes.

7. Secure WiFi Configuration

WiFi is the primary attack surface for most ESP32 devices.

WiFi Security Basics

Always use WPA2 or WPA3.
Never use open networks for production devices.
Validate certificates for TLS connections.
Avoid hardcoded credentials.

Provisioning WiFi Securely

Recommended methods:

BLE-based provisioning with encryption
Temporary AP mode with one-time password
QR code based provisioning

Avoid exposing WiFi credentials over unencrypted channels.

8. TLS and Secure Communication

All communication between ESP32 and servers must be encrypted.

TLS on ESP32

ESP-IDF supports TLS using mbedTLS with hardware acceleration.

Key points:

Always use HTTPS or MQTT over TLS.
Validate server certificates.
Use certificate pinning where possible.
Prefer ECC certificates for lower memory usage.

Common Mistakes

Disabling certificate verification
Using outdated TLS versions
Embedding private keys in firmware

9. Device Identity and Authentication

Every ESP32 device should have a unique identity.

Recommended Identity Methods

Device UUID burned at manufacturing
Per device certificates
Token based authentication with rotation
Hardware backed keys

Never use a single API key shared across all devices.

10. Secure OTA Updates

OTA updates are powerful and dangerous. If compromised, they allow full control of devices.

OTA Security Checklist

Sign firmware images
Verify signature before installing
Use TLS for OTA downloads
Implement rollback protection
Store update metadata securely

ESP32 supports secure OTA with signature verification integrated with Secure Boot.

11. Protecting Secrets in Firmware

Secrets often leak because developers store them incorrectly.

What Not to Do

Hardcode API keys in source code
Store passwords in plain text
Print secrets in logs
Expose secrets via debug commands

Recommended Approach

Store secrets in encrypted flash
Use key derivation where possible
Fetch short lived tokens from server
Rotate credentials periodically

12. Cloud Side Security Considerations

ESP32 security does not end at the device.

Server Responsibilities

Authenticate each device individually
Enforce rate limits
Validate payloads
Use role based access
Log suspicious behavior

Your cloud should assume that some devices may eventually be compromised.

13. Secure Manufacturing and Provisioning

Production is a critical phase where many security failures happen.

Secure Provisioning Flow

Flash minimal trusted bootloader
Burn Secure Boot key
Burn flash encryption key
Program device identity
Lock debug interfaces
Verify boot and connectivity

Avoid manual steps. Automate everything.

14. Lifecycle and Update Strategy

Security is not a one time task.

Long Term Security Practices

Support OTA updates from day one
Monitor vulnerabilities in ESP-IDF
Rotate keys when possible
Plan for device decommissioning
Provide factory reset with secure erase

15. Testing and Validation

Security features must be tested like any other feature.

Recommended Tests

Attempt firmware extraction
Attempt unsigned firmware boot
MITM TLS traffic
Replay command packets
Power glitch tests if high security is needed

Document test results and repeat them for each release.

16. Common ESP32 Security Mistakes

Avoid these common errors:

Leaving Secure Boot disabled
Not using flash encryption
Using shared credentials
Disabling TLS verification
Exposing debug interfaces
Relying only on network security

Conclusion

ESP32 provides strong security capabilities, but only if they are used correctly. Many insecure IoT devices exist not because ESP32 is weak, but because security was added as an afterthought. A secure ESP32 device requires attention at every layer, from silicon and bootloader to firmware, network, cloud, and manufacturing.

If you are building professional or commercial IoT products, enabling Secure Boot, Flash Encryption, proper device identity, and secure OTA updates is not optional. Even for hobby projects, following these practices will prepare you for real world deployments and protect users.

Security is a process, not a feature. Start early, design carefully, and treat every ESP32 device as if it will be attacked, because eventually, it will be.

Contribution Chronicles: My Hacktoberfest 2025 Journey

Yasir Nawaz — Fri, 31 Oct 2025 17:56:31 +0000

This year marked my third time participating in Hacktoberfest, and it was by far the most rewarding. I contributed to seven different repositories, primarily focusing on frontend development using TypeScript and React. Working with these technologies is a passion of mine, and it was great to see how my contributions helped improve various projects.

Why I Chose Frontend Projects

I love building user interfaces that make tools more usable and enjoyable for everyone. During Hacktoberfest, I worked on fixing bugs, enhancing accessibility, and optimizing UI components, often working closely with maintainers and other contributors around the world. It was a fantastic experience collaborating on code that reaches real users.

Highlights and Achievements

One of the most exciting moments was earning the Hacktoberfest T-shirt. It’s a small but meaningful badge that represents my effort and commitment. Additionally, I had a tree planted in my name through Treenation, which was a beautiful surprise. I also earned a variety of digital badges from Holopin that I can showcase on my profile to demonstrate my ongoing engagement with open source.

What Made This Year Special

Participating for a third time allowed me to reflect on my growth. I took on more challenging issues and worked with larger teams, which boosted my confidence and skills. The rewards added an extra layer of motivation. Collecting badges and seeing the tree planted made me feel like my work had a positive impact beyond just code.

Looking Forward

Hacktoberfest has become a yearly tradition that reminds me how fulfilling open source work can be. I plan to continue contributing, especially to projects friendly to newcomers and those that use TypeScript and React. Whether it’s fixing bugs or adding new features, I look forward to making an even bigger impact next year.

Thanks to Hacktoberfest, I feel inspired to keep learning, coding, and giving back to the open source community. It truly is about growing together and making a difference.

Building a RESTful API with Node.js and Express

Yasir Nawaz — Mon, 08 Apr 2024 12:02:50 +0000

In this tutorial, we'll explore how to build a RESTful API using Node.js and Express. RESTful APIs are a fundamental part of modern web development, allowing clients to interact with server-side resources through standardized HTTP methods. Node.js, with its non-blocking I/O model, and Express, a minimalist web framework for Node.js, provide an excellent foundation for building robust and scalable APIs.

Prerequisites

Before we begin, make sure you have the following prerequisites:

Basic knowledge of JavaScript
Node.js and npm installed on your machine
Familiarity with RESTful API concepts

Setting Up the Project

1. Initialize the Project: Open your terminal and navigate to the directory where you want to create your project. Run the command npm init and follow the prompts to create a new Node.js project.

npm init -y

2. Install Dependencies: Install Express and any other necessary packages using npm.

npm install express

3. Set Up the Express App: Create a new file named app.js (or any other name you prefer) and set up the Express app.

// app.js
const express = require('express');
const app = express();

// Middleware
app.use(express.json()); // Parse JSON requests

// Routes
// Define your routes here

// Start the server
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Designing the API

1. Define API Endpoints: Define the routes and HTTP methods for different resources. For example:

// Define routes for users
app.get('/users', (req, res) => {
  // Logic to fetch all users from the database
});

app.post('/users', (req, res) => {
  // Logic to create a new user
});

// Define routes for posts
app.get('/posts', (req, res) => {
  // Logic to fetch all posts from the database
});

// Define more routes as needed

2. Create a Data Model: Design the data model for the API using a database of your choice (e.g., MongoDB, PostgreSQL, MySQL).

// User model example using Mongoose
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

const userSchema = new Schema({
  name: { type: String, required: true },
  email: { type: String, required: true },
  // Define more fields as needed
});

const User = mongoose.model('User', userSchema);
module.exports = User;

3. Connect to a Database: Use Mongoose to connect to a MongoDB database.

const mongoose = require('mongoose');
mongoose.connect('mongodb://localhost/my_database', {
  useNewUrlParser: true,
  useUnifiedTopology: true
})
.then(() => console.log('MongoDB connected'))
.catch(err => console.error('MongoDB connection error:', err));

Implementing CRUD Operations

1. Create: Implement endpoint(s) for creating new resources.

app.post('/users', (req, res) => {
  const { name, email } = req.body;
  const newUser = new User({ name, email });
  newUser.save()
    .then(user => res.status(201).json(user))
    .catch(err => res.status(400).json({ message: err.message }));
});

2. Read: Implement endpoint(s) for retrieving existing resources.

app.get('/users', (req, res) => {
  User.find()
    .then(users => res.json(users))
    .catch(err => res.status(500).json({ message: err.message }));
});

3. Update: Implement endpoint(s) for updating existing resources.

app.put('/users/:id', (req, res) => {
  const { id } = req.params;
  const { name, email } = req.body;
  User.findByIdAndUpdate(id, { name, email }, { new: true })
    .then(user => res.json(user))
    .catch(err => res.status(400).json({ message: err.message }));
});

4. Delete: Implement endpoint(s) for deleting existing resources.

app.delete('/users/:id', (req, res) => {
  const { id } = req.params;
  User.findByIdAndDelete(id)
    .then(() => res.status(204).send())
    .catch(err => res.status(400).json({ message: err.message }));
});

Error Handling

Implement error handling middleware to catch and handle errors.

// Error handling middleware
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ message: 'Something went wrong!' });
});

Testing the API

Use tools like Postman or Insomnia to test the API endpoints and ensure they behave as expected.

Conclusion

In this tutorial, we've learned how to build a RESTful API using Node.js and Express. We covered setting up the project, designing the API, implementing CRUD operations, error handling, and testing. With this knowledge, you can create powerful and scalable APIs for your web and mobile applications.

Additional Resources

About the Author

I'm Yasir, a software developer with a passion for building scalable and maintainable web applications. Follow me on GitHub for more tutorials and projects.

This detailed tutorial will guide readers through the process of building a RESTful API with Node.js and Express, covering everything from project setup to testing and error handling. Feel free to adjust the content based on your preferences and the needs of your audience.

Happy coding and blogging!