Forem: Hassam Fathe Muhammad

[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.

Strengthening 🛡️ Brute Force Defense + Fallback Logs to Cover Data Loss in Case of Database Transaction Failures

Hassam Fathe Muhammad — Mon, 06 Oct 2025 18:03:33 +0000

We all use databases — whether it’s PostgreSQL, Firebase, or NoSQL like MongoDB. They’re the backbone for storing and accessing data in a structured way.

But here’s the thing: your database lives on a separate server. And when your web server (maybe running on Render or some cloud platform) tries to talk to it, things can go wrong — connectivity issues, timeouts, or even temporary downtime.

So what if a critical operation fails? Like logging a suspicious login attempt?

🔁 That’s where fallback logs come in.

I was working on strengthening login security to prevent brute force attacks. You’d think brute force isn’t easy to pull off — but once you understand how attackers operate, you realize it's a real threat.

To stop it, I used the express-rate-limit middleware in Node.js — setting request limits per IP on the login route. Pretty standard.

Now, I was logging each login attempt's IP address and userID into MongoDB.

But then a few problems came up:

🔸 Problem 1: MongoDB Fails? Data Loss.

So I added a fallback using Node’s fs module. If MongoDB logging fails, the data (IP + userID) goes into a local file. Simple but effective — no loss of important info.

🔸 Problem 2: IP Address was always ::1 or 127.0.0.1 on Render

Because Render (like many cloud platforms) uses a reverse proxy, the actual client IP wasn’t being captured — instead, Express was logging everything as localhost.

This weakens the brute force protection — because every attacker seems to come from the same IP.

✅ Fix: I told the Express app to trust the proxy by adding:

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

After this, the correct IPs started showing up via req.ip. Now the rate limiter and logging actually work as intended.

🧠 Takeaway: You can’t fully rely on external systems — whether it’s a DB or the platform’s default behavior. 👉 Always have fallbacks, 👉 Always verify what data you’re actually capturing, 👉 And from a cybersecurity point of view — don’t just rate-limit blindly. Make sure it’s working accurately and intelligently.

🔐Security-Proofing My Full Stack App Against XSS Attacks (Cross-Site Scripting)

Hassam Fathe Muhammad — Wed, 24 Sep 2025 17:12:56 +0000

As my skills and enthusiasm keep getting forged in Full Stack Development, the prevention of hacking and securing my web apps is something I seriously gave time to — especially after discovering the weak points and vulnerabilities many modern apps still carry.

After digging into these flaws, I began exploring their real-world consequences and how to fix them practically.

🎯 First Target: XSS (Cross-Site Scripting)

One of the vulnerabilities I tackled first was XSS (Cross-Site Scripting) — the injection of malicious scripts via input forms, comment boxes, search queries, etc.

These malicious scripts, due to their foreign nature, are executed in the browser, often leading to cookie theft, session hijacking, or UI manipulation.

🛡️ Understanding Browser Defenses

To stop these behaviors, browsers can block such scripts if you define a Content Security Policy (CSP). These policies are sent using headers — specifically via the helmet module (a middleware for Express apps in Node.js).

⚙️ My Real-World Test on InspireSphere

To practically test it, I picked InspireSphere — my own web app — as the test environment.

I injected some basic script tags inside the User Content Submission Page, specifically in the narrative section.

🧪 Result:

The script wasn't triggered in the browser, but *was saved to the database. *
✅ This is called Stored XSS — where a malicious script is stored in the database and runs whenever it's rendered.

Then I tested something more subtle and sneaky: I injected a script using an tag with an onerror handler (like onerror="alert('XSS Success')"), and that was executed every time the content was rendered from the backend.

💡 Eye-Opening Moment: Cookie Theft Simulation

Here’s where it got more real.

I tried to simulate cookie/token theft by injecting a script using a hyperlink tag. When clicked, it executed JavaScript that sent document cookies to my own test API endpoint.

😮 This was the moment that really exposed to me how dangerous even a small XSS can be.

> This entire experience became a powerful cybersecurity lesson. Many developers never test their apps from the attacker’s perspective — and if I hadn’t tried this, I wouldn’t have found it either.
_

🛠️ The Fix: CSP + Safe Scripting Practices

To fix all of this:

I added CSP Headers using helmet in Node.js.
I enforced that only scripts served from my /public/js/... path (trusted backend) are allowed to run.
I disabled inline scripts and styles, which are a huge vulnerability and prevent proper CSP enforcement.

📌 Final Notes: What Devs Should Watch Out For

Many developers — especially beginners — use inline scripts and inline CSS without realizing that:

You can't enforce CSP properly with them.
They open the door to malicious injections and XSS attacks.

✅ Final Result

After complete testing and securing every layer, ➡️ My app InspireSphere is now fully protected against XSS attacks.

✅ Scripts and styles are served only from trusted backend sources. ✅ A strong Content Security Policy is in place and enforced. ✅ Malicious injections are sanitized and blocked.

💬 If you’re a dev building your own app — test like a hacker, fix like a pro.

🚀 Upgrading & Utilising My Model (ML/AI Integration Series)

Hassam Fathe Muhammad — Sat, 13 Sep 2025 21:33:23 +0000

Continuing from: “🚀 My First Step Towards AI/ML Model Integration | Inspire Sphere”

Back then, the ML/AI model I deployed to get categories of the quotes written by users was trained on data using the MultinomialNB algorithm from naive_bayes. The accuracy of my model was not more than 17%, mainly due to several incompatibilities and the absence of supportive parameters in the TFIDF Vectorizer, as well as an inappropriate use of MultinomialNB.

This algorithm works well only when the features (words) in the document are independent of each other, as it calculates probabilities by taking the product of individual probabilities. It's a good fit where text can be classified based on specific independent flagged words, like in detecting spam or fraud in an email.

However, my previous model/system lacked important TfidfVectorizer parameters like:

stop_words
ngram_range
max_df
min_df

These parameters help in converting the text into a cleaner and more structured numeric form, making it more ready for classification.

What’s New Now?

So, the next algorithm to take the place of MultinomialNB is Logistic Regression from linear_model. Unlike the former, this doesn’t assume that features are independent — it considers relationships between word appearances in the document.

The results were notably better. When my first model categorized this quote on Inspire Sphere as:

Category: Love “A wolf saw me when I was alone… I was that wolf”

Then the improved model categorized it as:

Category: Humour

That was quite a significant and meaningful difference.

Why This Upgrade Mattered

After upgrading my model, I realized that the real value of an AI model also depends on the data processing and how it interacts with real users.

I made the model predict the category of quotes written by users on Inspire Sphere to auto-fill the title input field. This made the platform look more professional and supportive — helping users feel guided and saving time.