Forem: Hassam Fathe Muhammad

Apart from CRUD work in backend, there is a lot more to learn and implement in your projects to allow scalable, powerful, and reliable system design. As most of us full-stack and backend developers work with APIs for user-oriented operations which are being triggered from frontend by end users in their various tasks, and then the response of those APIs for that task informs user and drives their work forward, navigates them to further pages, fetches them the required info, and provides them with services.

But not all types of workflows can be given to a designed API and then accomplished in short time with that one single API — it can be, but not on user's waiting. The user expects the web app or app response for his or her simple triggered task. But it is the backend which knows how many actions and tasks must be performed and in which order.

The Solution: Work Queues

For this we use Work Queues and give the work to the workers, whereas a success or work-in-progress response is being sent to the user — allowing it to move along rather than waiting for the whole set of backend operations.

My Implementation Journey

For explanation and demonstration, I will be implementing this concept in one of my projects which involves a set of tasks. As I also worked with Redux for state management in my 'Nur Fashions' e-commerce web app, I decided further upgrade of this project with queues & jobs would be better for learning and productive for this project, adding value to it.

Technology Stack

The module/library I used for this was BullMQ and the storage and execution engine used was Redis, as BullMQ is made on top of Redis. So I used Docker to run my Redis image and allow connection from localhost.

Use Case: Order Processing

Now in my Nur Fashions e-com web app, I selected the order processing aspect. As the backend was already saving order entry to the database and giving success response, now as we discussed, we did not need to overwhelm this API and add other required tasks into it such as:

Update Inventory for selected ordered items
Send Email to customer (user)
Generate Invoice

which I now gave to the workers of the queue.

System Architecture & Design

Now as I always try to design systems for scalability and modular for cleaner and helpful abstraction, so I made up:

Queue Config File

Job Addition From Controller Code:

await orderQueue.add("processOrder", {
    orderId: orderData.orderId,
    orderEmail: orderDetails.customer.email,
    items: orderDetails.items
}, {
    attempts: 5,
    backoff: {
        type: "exponential",
        delay: 5000
    },
    removeOnComplete: 100,
    removeOnFail: false,
});

Worker Task Handling File along with limiter and retry logic

Running Workers Separately

Now it was observed and learned by me that workers and queues must be started separately. So as this was a crucial part of server/backend, I used a module called 'concurrently' which executes a list of commands at the same time.

So I made up one index.ts main worker file which was importing Order Worker File, allowing to start different workers in future.

Handling Job Failures: The Critical Part

This is where I got this concern of what if any task/job fails. So I got confronted by different approaches in which the more obvious all along was to have a vast and detailed DB schema for order table/collection. So I made up properties/attributes such as:

inventoryProcessed: Boolean,
inventoryProcessedAt: Date,
emailSent: Boolean,
emailSentAt: Date,
invoiceGenerated: Boolean,
invoiceGeneratedAt: Date,
processing: {
    inventoryError: String,
    inventoryLastAttempt: Date,
    emailError: String,
    emailLastAttempt: Date,
    invoiceError: String,
    invoiceLastAttempt: Date
}

Dual Storage Strategy

This allowed me to update info for dead jobs handling and debugging. Along with this, I used Redis to store flags based on completion/failure of jobs:

try {
    const inventoryProcessed = await redis.hget(`order:${orderId}:flags`, "inventoryProcessed");

    if (inventoryProcessed !== "1") {
        console.log("Updating Inventory: ", orderId);
        await InventoryController.updateInventoryPostOrder(items);

        await Promise.all([
            await redis.hset(`order:${orderId}:flags`, "inventoryProcessed", "1"),
            await order.updateOne({orderId}, {
                inventoryProcessed: true, 
                inventoryProcessedAt: new Date()
            })
        ]);     
    } else {
        console.log("Inventory Already Processed, ", orderId);
    }
} catch (error: any) {
    errors.inventory = error.message;
    console.log(`Error While Updating Inventory, ${orderId}, `, error.message);

    await order.updateOne({orderId}, {
        "processing.inventoryError": error.message,
        "processing.inventoryLastAttempt": new Date()
    });
}

As in the same way for other tasks in this order process.

Then I also configured the limiter as down below and did exception/error handling along notifying the admin for failed jobs:

{
    connection: { host: "127.0.0.1", port: 6379 },
    limiter: {
        max: 10,
        duration: 10000,
    },
    concurrency: 5
}

///////////

worker.on("completed", (job) => {
    console.log(`Job ${job.id} completed Successfully`);
});

worker.on("failed", async (job, error) => {
    console.error(`Job ${job?.id} failed, `, error.message);

    if (job && job.attemptsMade >= 3) {
        await AlertController.sendAlertToAdmin({
            orderId: job.data.orderId,
            error: error.message,
            attempts: job.attemptsMade
        });
    }
});

worker.on("error", (error) => {
    console.error("Worker Error, ", error);
});

Conclusion

Now this is how I learned and implemented worker queues using BullMQ to add scalable, value, and reliable features to my backend, upgrading my backend skill stack and keeping users moving along on the frontend.

Real engineers:

Design for scale from the start
Handle failures gracefully
Keep users informed without making them wait

[Boost]

Hassam Fathe Muhammad — Sat, 28 Mar 2026 09:27:44 +0000

klement Gunndu

Mar 25

Vibe Coding Got You Started. These 5 Skills Keep You Employed.

#ai #beginners #career #programming

Comments 16

6 min read

Just Did Work On OWASP A05

Hassam Fathe Muhammad — Fri, 27 Mar 2026 15:23:12 +0000

Hassam Fathe Muhammad

Mar 27

OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)

#security #systemdesign #owasp

Comments

3 min read

OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)

Hassam Fathe Muhammad — Fri, 27 Mar 2026 15:22:40 +0000

As I have been working with OWASP Top 10, so far I have studied A01 to A04 and performed remediations according to them on my projects, so I can have an idea of security and standard testing of my web apps. In this article, I would like to tell you about my work regarding A05, which is Security Misconfiguration.

t is observed by me that many of the aspects addressed in one OWASP category can also be addressed in more than one category. So this is more about discipline while developing a web app.

In my work on OWASP A05, I performed the following remediations and improvements:

Note: As some aspects are also addressed in more than one OWASP category, my work is more likely inclined toward one specific category in this article.

Environment Configuration

One of the aspects that many beginner developers miss out on—and exhibit work-shyness in—is not preparing separate environments for:

Development (Project Making)
Local (Running on a local closed network)
Production (Deploying the project as delivered and ready to meet the internet)

This configuration can be done by preparing .env files accordingly and editing them for the type of project start.

**For example: **It is best and advised to have this variable:

NODE_ENV=production

The variable value can be changed according to the project environment like "dev" for development, "local" for local, and "prod" for production.

This allows necessary condition checks and flag triggering such as:

if (process.env.NODE_ENV === "production") {
  app.set("trust proxy", 1);
}

This allows IP address logging and other rate-limiting and security methods to be applied.

Note: Proxy must be trusted with this flag only if you are using NGINX or another trusted reverse proxy like Cloudflare or reputed hosting services.

Secure HTTP Headers

Another security misconfiguration that must be handled is the use of Helmet for securing HTTP headers.

import helmet from "helmet";

app.use(helmet());

This adds:

Content-Security-Policy
XSS Protection
Frameguard
HSTS

CORS Configuration

Another important configuration is CORS:

app.use(cors({
  origin: ["https://yourfrontend.com"],
  credentials: true
}));

One should regularly identify their domains and use the correct URLs in their CORS configuration.

Hide Sensitive Errors

Many developers forward backend errors to the frontend for quick debugging, like:

res.status(500).json({ error: err });

This is not advised, as it may expose backend structure, repositories, or system limitations.

Instead, use standard messages such as:

res.status(500).json({ message: "Internal Server Error" });

For debugging, use server logs:

try {
  // Logic
} catch (error) {
  console.error("Error While Processing In (Endpoint)", error);
  res.status(500).json({ message: "Internal Server Error" });
}

Disable Stack Traces & Info Leaks

Information about backend resources matters a lot. It allows attackers to guess weaknesses and evaluate your servers.

We can use:

app.disable("x-powered-by");

This hides:

X-Powered-By: Express

Enforce HTTPS

When using hosting services, they often handle HTTPS automatically.

But when deploying manually using a reverse proxy like NGINX, ensure:

NGINX + Certbot setup
Redirect HTTP → HTTPS
Install SSL certificate

Usually, this is part of NGINX deployment.

Secure Cookies

While setting cookies from the backend, ensure the following:

res.cookie("token", token, {
  httpOnly: true,
  secure: true,
  sameSite: "strict"
});

Remove Default Credentials

During development, many developers use default credentials for quick testing.

Removing these from the database is very important.

If missed, attackers might try:

Username: admin
Password: admin

and gain admin access.

Advanced Insight

Security Misconfiguration is NOT a bug. It’s a discipline problem.

Most developers:

Focus on features
Ignore deployment & configurations

Real engineers:

Secure systems at both infrastructure and application levels

Redux vs React Context: A Practical Perspective from a Real Project

Hassam Fathe Muhammad — Wed, 28 Jan 2026 16:39:55 +0000

Back then, I started using React Context in my web apps mainly for auth and session-related info/status.

The idea of Context is simple: it is created for the app (its components) so that prop drilling can be avoided, and the state can be easily accessed by the components that actually need it—while ensuring proper updates and usage of state data.

The React Context API (createContext, useContext, useState, etc.) worked well for me, and I’ve used it in many of my web apps (React + Next.js).

What I liked the most—and what I think many developers will find helpful—is how it eliminates prop drilling and helps in understanding the layout structure when using a Context Provider. I became quite comfortable with React Context.

But there is also another library designed for managing shared state and complexity: Redux.

Enter Redux

Using Redux requires understanding a few core concepts:

Store
Slices
Reducers
Actions

The Store, which is the global state container, is singular—there is only one store in an app. Inside it, you have multiple slices, where each slice represents a specific feature or concern and contains its state, reducers, and actions.

I’m not writing this article to teach Redux or deeply explore its internal structure. Instead, I’ll explain my thinking using an example from one of my projects.

A Real Project Example

I have an e-commerce-based Next.js web app called Nur Fashions. It’s a template-nature, client-based project.

In this project, I’m using React Context for:

Authentication
Cart management
Location (for currency, etc.) From my experience, Context API is completely fine for these use cases.

Why?

No complex backend involvement
No heavy backend syncing
No asynchronous workflows
Fewer uncertain or branching operations

So for these parts of the app, React Context is more than enough—there is simply no need for Redux here.

Where Redux Makes Sense

However, one important process in this app is the ordering flow after cart checkout.

This process needs to be handled very carefully:

It involves asynchronous operations with the backend
It requires clearly defined and strongly typed states (loading, success, failure, etc.)
It has the potential to grow in complexity and scalability, with more backend syncing and business logic added over time

For this reason, using Redux here felt both reasonable and professional. So I set up Redux (store + slice) and wrapped it with a provider in the layout.

A Key Realization

While working on this, I came across a very important professional insight:

Redux is NOT about lifetime. Redux is about complexity.

Before understanding this, I was more convinced of the idea that Redux should only be used for long-living context or global state. But now my perspective has changed.

What truly matters is how complex and scalable the state logic is, not how long the data lives.

And that, for me, is the real distinction between React Context and Redux.

OWASP Top 10 – A04: Insecure Design (Remediation Perspective)

Hassam Fathe Muhammad — Wed, 28 Jan 2026 15:54:00 +0000

As I have been trying to cover the OWASP Top 10 to make my full-stack development skills more valuable, standardized, and aligned with the cybersecurity domain, the topics I have already covered include:

A01 – Broken Access Control
A02 – Cryptographic Failures
A03 – Injection

In this article, I will talk about A04 (Insecure Design), its remediation, and how it differs from A01 in some important ways.

What A04 (Insecure Design) Focuses On

A04 focuses on the absence of proper logic and security mechanisms at the design and implementation level of a web application or website, which ultimately makes it insecure.

Some practices that commonly lead to Insecure Design include:

Trusting the client-side too much
Not designing APIs and gateways according to server-issued protocols and rules
Performing sensitive processing on the client side
Fetching sensitive data on the frontend when it is not required

Practical Handling of A04 in My Project

In this article, I’ll explain some of the practices I eliminated to avoid A04 (Insecure Design) issues in one of my projects, Alpha Connect Hub (now IoT Nerve).

Handling A04 across the entire project and all modules is my responsibility as a skilled full-stack developer to ensure that no cybersecurity issues are introduced due to weak design decisions.

To keep this article focused and practical, I will explain A04 using a specific module example.

Example Module: MQTT Broker Server Credentials

This module is responsible for setting up credentials (username and password) for the MQTT Authentication Service, which is required to connect to the MQTT Broker.

Insecure Practices Eliminated

One of the main vulnerabilities that must be rooted out in this module is:

Fetching the password on the frontend (even in hashed form)

The involvement of passwords or authentication keys on the frontend directly contributes to Insecure Design.

Another insecure practice that must not be allowed is:

Allowing the password-changing mechanism to proceed without verifying the original (old) password

Requiring the previous password ensures ownership verification and keeps access control intact.

Route Protection & OWASP Categorization

All routes used in this module are protected and require a server-issued token, enforced through middleware, before any real operation is performed.

Negligence in protecting such routes falls under A01 – Broken Access Control
The absence of proper route design, reasonable parameters, and a secure & safe output/result schema falls under A04 – Insecure Design

From Internship to Enterprise Development: My Journey into MDM, EMM & API Publishing

Hassam Fathe Muhammad — Sat, 01 Nov 2025 16:08:30 +0000

🔒 Disclaimer / Notice

This article is purely based on learning, exploration, and research into MDM, EMM, and API publishing technologies during my internship and personal projects.

No production-level deployments, enterprise bypassing, or unauthorized development for business gains were performed.

All experiments were done in local/demo environments and with educational intent.

The purpose of this write-up is to share knowledge and document my journey, not to promote or replicate enterprise deployments without proper authorization.

🏁 Starting Point: My Internship at Mercurial Minds

During my internship at Mercurial Minds (M.M), I was placed in the Enterprise Mobility Management (EMM) / Mobile Device Management (MDM) department.

At first, I wasn’t fully clear on what these systems were about — tools like Samsung Knox and other enterprise EMM platforms felt overwhelming.

But gradually, I discovered that EMM/MDM isn’t just about managing devices — it’s a core product area that many leading software companies invest in.

This was my first real exposure to enterprise-level technology, beyond the world of small-scale software projects.

🔍 Diving Deeper: From Confusion to Curiosity

As I got hands-on experience with an EMM/MDM portal on a demo server, my curiosity grew. With some research, I found that the portal was powered by the Entgra IoT Server.

Instead of stopping there, I pushed myself to self-learn:

Studied how the portal behaves behind the UI.
Explored the REST APIs that power MDM workflows.
Looked into open-source repositories on GitHub.
Broke down how Java, JDKs, and Maven tie together in Carbon Kernel–based projects.

At first, things like API gateways, publishing flows, and claim-based authentication seemed abstract. But slowly, the architecture started making sense — I realized these weren’t just “APIs,” they were enterprise connectors between identity, security, and data.

🧩 Connecting the Dots: From Internship to My Own Projects

While experimenting, I even evaluated Entgra UEM 6 (using my Alpha Tech business email). That opened doors to WSO2 API publishing features, which taught me that:

✅ APIs aren’t just direct DB calls — they’re published assets, controlled, secured, and monitored.

✅ A single published API serves all users/tenants, while tokens and claims decide whose data flows through.

✅ Enterprise systems solve the question:

“How do I ensure each user only sees their devices, even though everyone is calling the same endpoint?”

🧠 Applying It: Building My Own System

This was a big shift. I wasn’t just thinking like an intern anymore — I was thinking like:

A developer building scalable solutions.
A founder shaping my own product direction.

I applied these lessons in my own project — Alpha Connect Hub (under Alpha Tech):

Built a Node.js backend for device management.
Used WSO2 API publishing to expose those APIs securely.
Integrated OAuth2 / JWT-based access tokens to ensure each request is linked to a unique user identity.
Experimented with building a Java backend to simulate MDM/EMM workflows on a Carbon Kernel stack.

⚙️ Lessons From the Struggle

This journey wasn’t smooth:

Running large Carbon Kernel projects on macOS was painful.
Debugging JDK versions, Maven builds, and UEM server issues tested my patience.
Figuring out why GET /devices worked only via the API Gateway (and not as a direct DB call) forced me to learn about invoker endpoints, token claims, and mediation policies.

I learned that one API is published for everyone, but the token’s claims (like user_id) make it unique per user.

Every error — from a 401 auth failure to a class-not-found exception — taught me something new.

Through this struggle, I learned the real difference between project-level coding vs. enterprise-level development:

Projects require coding skill.

Enterprise systems require architecture, patience, and persistence.

🌐 What’s Next

I’m now preparing to set up a Linux server environment, since Carbon Kernel–based systems run more stably there compared to macOS.

My roadmap is clear:

Build enterprise-ready backend systems.
Combine MDM, EMM, and API publishing into scalable, secure products.
Use this foundation to grow Alpha Tech into a company that builds solutions, not just apps.

💡 Final Reflection

Looking back, this wasn’t just an internship. It was the spark that helped me:

Transition from learning projects → building products.
Move from coding → thinking enterprise.
See technology not just as tools, but as part of a bigger ecosystem of identity, security, and scale.

My journey into enterprise development has only just begun. 🚀

Vulnerability Remediation (Cybersecurity Patch) by Strengthening Cryptography & Data Protection (OWASP A02)

Hassam Fathe Muhammad — Fri, 17 Oct 2025 19:37:05 +0000

A02: Cryptographic Failures

Being a full stack developer, I try my best to make my web apps scalable and secure. The security of a web app not only shows its ability to defend and survive hacking attacks, but it also enables one to learn the connection and intersection of different domains of knowledge and skills that actually happen at many stages in the development journey.

Enforcing HTTPS

In OWASP A02 (Cryptographic Failures), I explored how to perform vulnerability remediation and apply fixes. The enforcement of HTTPS, proper TLS usage, encryption of data, and secure hashing methods are all part of this A02 practice.

I started exploring and found out about the express-sslify module, which helps enforce HTTPS so that requests sent by clients are only accepted over HTTPS, responding with a 301 redirect if not.

I used the module in my server file:

app.set('trust proxy', 1);

This allows the app to apply settings for trusting the proxy headers.We need this because deployment services (CaaS platforms) like Render, which I used, rely on reverse proxies such as Nginx or Cloudflare. Locally, the backend (Node.js) starts the server via HTTP, and the reverse proxy provides HTTPS to the client, forwarding it back to the HTTP routes internally.

if (process.env.NODE_ENV === 'production') {
    app.use(enforce.HTTPS({ trustProtoHeader: true }));
}

With this code, HTTPS is enforced. It checks the request protocol, and if the initial client request is not HTTPS, it issues a 301 redirect to the correct HTTPS URL.

Checking With curl -I

curl -I http://alphaconnecthub.onrender.com/profile/getProfiles

Response:

HTTP/1.1 301 Moved Permanently
Date: Thu, 04 Sep 2025 21:47:14 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Location: https://alphaconnecthub.onrender.com/profile/getProfiles
cf-cache-status: DYNAMIC
Server: cloudflare

Using Argon2 Over BcryptJS for Better Hashing

For password hashing, I used Argon2 instead of BcryptJS:

const hashedPassword = await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 2 ** 16,
    timeCost: 3,
    parallelism: 1,
});

Why Argon2?

OWASP recommends Argon2 as one of the strongest password-hashing algorithms.
It is memory-hard (resistant to GPU/ASIC brute-force attacks).
It provides stronger defense against modern cracking attempts compared to Bcrypt.

Why Not Scrypt?

During my exploration of hashing methods, i also came across scrypt. It is a memory-hard algorithm and is even used in some cryptocurrencies like Litecoin and Dogecoin because of its ability to make large scale hardware attacks expensive. Scrypt is definitely stronger than older methods like Bcrypt in many cases.

But When i compared it with argon2, i found that argon2 is the more modern and recommended option. Argon2 was the winner of the Password Hashing Competition and is recommended by OWAPS and NIST. It gives better protection against side-channel attacks and has more flexible settings like memory usage, time cost, and parallelism.

So while scrypt is still secure, i decided to use argon2 in my project because it is the latest best practice for password hashing and aligns with security standards.

Hiding Auth Token Names (Cookies) in Environment Variables

I wrote the token names in the .env file. These are used when storing and issuing auth tokens, making it more difficult for attackers to inspect an active logged-in session and guess cookies/tokens.

Enabling HTTP-Only Flag in Cookies

Finally, I enabled the HTTPOnly flag when setting cookies. This disables JavaScript access, which prevents cookie theft or manipulation by malicious scripts.

💡Idea: Using VPN-Type Virtual Links for Secure IoT Data Flow

Hassam Fathe Muhammad — Tue, 14 Oct 2025 19:13:53 +0000

🔸🔸🔸🔸🔸🔸 RESEARCH REFLECTION 🔸🔸🔸🔸🔸🔸

While experimenting on Hack The Box, I realized something interesting — the same VPN tunnels we use in cybersecurity labs could potentially revolutionize how IoT devices communicate securely.

🕚 Recently, while learning how to get data from a Linux machine on Hack The Box, I started by scanning the host IP through a virtual network using OpenVPN.
But I couldn’t even ping the host — it was isolated in a separate network. I had to use the .ovpn file to connect via utun.

That got me thinking: since my machine couldn’t access the box directly over the internet, what if IoT networks used a similar secure, virtual link model?

🔹 Case 1: Near the Device Setup

If the installation is large (e.g., a CPU or GPU-based edge node in a house, factory, or shop), LAN makes sense.
Most algorithms can run locally, processing around 70% of the data before sending it — encrypted — to the cloud or main node.

🔹 Case 2: Away from Device Setup

If that 70% processing node is far away, LAN becomes impractical due to cable management, maintenance, and cost.

So, what if we provide each IoT device (like ESP32 or Raspberry Pi) with its own OpenVPN configuration file — letting it connect to a private network before publishing data via MQTT?
Only devices inside that VPN could reach the broker, shielding the system from external access.

We could even rotate the VPN configs periodically for extra security.

And since utun or tun0 interfaces can be controlled with iptables, we can define exactly what traffic passes through.

For developers, SSH access to the edge node could happen through the same VPN — ensuring secure, controlled maintenance.

🔚 Just an idea — but combining VPN-type isolation with MQTT and edge computing could make IoT communication far more secure.
What do you think — could this approach scale in real-world IoT environments?

🔒 Vulnerability Remediation (Cybersecurity Patch) 🛠️ by Avoiding Broken Access Control 🚫

Hassam Fathe Muhammad — Sat, 11 Oct 2025 18:13:21 +0000

This was my second attempt at finding areas I needed to practice in, specifically related to cybersecurity skills — particularly Vulnerability Remediation.

Before I get into how I strengthened the access control, I want to first explain the method I used to exploit a vulnerability in one of my own web apps.

My Experiment (Ethical Practice)

I acted exactly as a hacker would to try and gain access to certain services of my web app.

Important: Before proceeding further and sharing my experimental experience — please never apply such knowledge to someone else’s projects, web apps, or services without proper consent. Always do this only for learning and exploring vulnerabilities in your own environment.

How I Exploited My Own App

Targeting Admin Routes I went to the admin routes (pages) of the targeted web app and opened the Network tab in Chrome DevTools. From there, I examined the requests — pages, scripts, and other files — and was able to understand the JavaScript logic used to call APIs like updateData and savePortfolioData.
Identifying Admin-Level APIs You can usually guess admin-level API functions by inspecting the client side:
Payload Analysis I captured the payloads received from client-side APIs to see what data was coming in. After slightly modifying this data, I tested it in Postman.
Executing the Exploit By changing the payload structure, I was able to get a 200 OK response after updating the data. ✅ Result: I had gained access to admin-level functions/panel on my own app.

A Surprising Finding: CORS Didn’t Interfere

I was a little surprised that CORS didn’t block me at all. After researching, I found that CORS is enforced in browsers, whereas tools like Postman or local requests bypass browser restrictions — making such API calls less likely to be blocked for attackers.

The Root Cause

If you haven’t implemented middlewares like:

Token verification (checkToken)
Role verification (checkRoles)

…then your API routes can be abused by any regular user, customer, or even a random visitor.

The Fix (My Cybersecurity Patch)

In my remediation process, I ensured that:

All role-specific routes require both token validation and role validation.
Only authorized roles can access admin functions.

By doing this, I prevented normal/non-admin users from exploiting those API routes.

Key Takeaway

Broken Access Control is one of the most critical vulnerabilities in web apps. Even if your front-end hides admin options, your APIs must be secured with proper authentication and authorization — otherwise, it’s just a matter of time before someone finds and abuses them.

Final Thoughts

This was a valuable learning experience for me — not only did I strengthen my app’s security, but I also sharpened my vulnerability remediation skills by patching a flaw I had personally exploited in a safe environment.

🛡 My Tip for Developers:

Always secure your APIs as if your front-end doesn’t exist. If your backend can’t trust the request source, it shouldn’t execute sensitive actions.