DEV Community: Raji Sherifdeen ayinla

The Day "Standard Security" Wasn't Enough: A Deep Dive into HTTP Headers

Raji Sherifdeen ayinla — Wed, 31 Dec 2025 14:16:44 +0000

While I was working on a recent repository, I found that the code had a massive setup for helmet.js.

Before I was onboarded on this project, I used to just call app.use(helmet()) and call it a day. I treated it like a "black box"—a magic spell that made my app secure. But this project used a deep configuration object that I didn't understand.

My curiosity got the best of me. I realized that by using the default settings, I was only scratching the surface of web security. After hours of research and testing, I’ve broken down the advanced headers you actually need to know.

1. The "Traffic Controller": Content Security Policy (CSP)

The default Helmet CSP is a good start, but it often breaks modern front-ends (like those using inline styles or Google Fonts).

The Concept: CSP tells the browser exactly which sources of content (scripts, CSS, images) are trusted. If a hacker tries to inject a script from malicious-site.com, the browser will simply refuse to run it.

Practical Example:
If your app uses Google Fonts and a specific API, a "standard" setup won't cut it. You need a granular policy:

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      "default-src": ["'self'"],
      "script-src": ["'self'", "trusted-scripts.com"],
      "style-src": ["'self'", "fonts.googleapis.com"],
      "img-src": ["'self'", "data:", "images.com"],
      "connect-src": ["'self'", "api.example.com"],
      "upgrade-insecure-requests": [],
    },
  })
);

2. The "Strict Parent": HSTS (Strict Transport Security)

You might think redirecting HTTP to HTTPS is enough. It’s not. There is a small window called a Man-in-the-Middle (MitM) attack where a hacker can intercept the request before the redirect happens.

The Concept: HSTS tells the browser: "Don't even try to use HTTP for the next year. Only talk to me via HTTPS."

Practical Example:

app.use(
  helmet.hsts({
    maxAge: 31536000, // 1 year in seconds
    includeSubDomains: true, // Apply to all subdomains
    preload: true, // Request to be included in browser HSTS preload lists
  })
);

3. The "Privacy Guard": Referrer-Policy

When a user clicks a link on your site that leads to another website, your URL is often sent in the "Referer" header. If your URL contains sensitive data (like /reset-password?token=123), that external site now has your token.

The Concept: This header controls how much information is shared when a user leaves your site.

Practical Example:

// Only sends the origin (domain) rather than the full URL when moving to another site
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));

4. The "Feature Lockdown": Permissions-Policy

This is one of the newer, more powerful headers. It’s formerly known as Feature-Policy.

The Concept: It allows you to disable browser features that your site doesn't need. If your site doesn't use the camera or microphone, why leave them accessible? If a malicious script ever runs on your site, this header ensures it can't turn on the user's webcam.

Practical Example:

// Note: In newer versions of Helmet, this is often set manually
app.use((req, res, next) => {
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  next();
});

5. The "Anti-Sniffer": X-Content-Type-Options

Browsers try to be "smart" by guessing the file type (MIME type) of a file. If a user uploads a text file containing JavaScript code, a browser might try to execute it as a script.

The Concept: Setting this to nosniff forces the browser to stick to the Content-Type sent by the server. If the server says it's an image, the browser treats it as an image—period.

Practical Example:

// This is included in default helmet(), but vital to understand
app.use(helmet.noSniff());

Summary Table: What does what?

Header	Purpose	Real-world Analogy
CSP	Controls where scripts/styles come from	A guest list for a private party
HSTS	Forces HTTPS	Only opening the door for armored trucks
Referrer-Policy	Hides your URL from other sites	Using a shredder on sensitive documents
Permissions-Policy	Disables hardware (Camera/Mic)	Disabling the mic on a laptop you don't use

Conclusion

Switching from app.use(helmet()) to a custom configuration was a turning point in my career. It moved me from "coding things that work" to "engineering things that are secure."

The next time you start a project, don't just copy-paste your security middleware. Take 10 minutes to define exactly what your app needs. Your users will thank you.

How do you handle security headers in your apps? Do you use a library or set them manually? Let's chat in the comments!

CI/CD Explained for Beginners (Using GitHub Actions Terms)

Raji Sherifdeen ayinla — Tue, 30 Dec 2025 00:33:28 +0000

When you’re new to development, CI/CD can sound like one of those “senior developer things” — important, but abstract and intimidating.

In reality, CI/CD is just about automating the boring but critical parts of shipping code.

Let’s explain it through a simple story, using GitHub Actions concepts you may have already seen:
workflow, event, jobs, steps, runner, and artifacts.

No buzzwords. No magic.

The Problem CI/CD Solves

Imagine this workflow:

You write code
You test it manually
You build it manually
You deploy it manually
Something breaks anyway

This process is slow, repetitive, and stressful — especially as a project grows or more people join.

CI/CD exists to automate this process.

CI (Continuous Integration) checks your code automatically
CD (Continuous Delivery / Deployment) prepares or ships it automatically

GitHub Actions is one tool that helps you do this.

Think of CI/CD as a Robot Assistant

CI/CD is like a robot that watches your repository and says:

“Whenever something important happens, I’ll take care of the routine work.”

That robot is controlled by something called a workflow.

Workflow: The Plan

A workflow is a set of instructions written in a YAML file.

It answers two questions:

When should automation run?
What should it do?

Example idea:

“When code is pushed, run tests and build the app.”

The workflow just sits there until something wakes it up.

Event: What Triggers Everything

An event is what starts the workflow.

Common events include:

Pushing code
Opening a pull request
Running on a schedule

Story-wise:

You push code → an event happens → the workflow starts.

No event, no automation.

Jobs: The Big Tasks

Once the workflow starts, it creates one or more jobs.

Each job represents a big task, such as:

Running tests
Building the application
Deploying the app

Jobs can:

Run in parallel
Depend on other jobs

Example logic:

“Only build the app if the tests pass.”

Runner: The Machine Doing the Work

A runner is the machine that executes a job.

It’s just a computer:

Linux, Windows, or macOS
Hosted by GitHub or by you

Think of it like this:

Jobs don’t do work themselves.
They ask a runner to do it.

Steps: The Small Instructions

Each job is broken down into steps.

Steps are the smallest units of work:

Check out the code
Install dependencies
Run tests
Build files

Steps run one after another, in order.

If a step fails, the job stops — which is exactly what you want.

Artifacts: What You Keep After the Job

Some jobs produce useful files:

Build outputs
Test reports
Logs

Artifacts are files you choose to save after a workflow run. Those are the files you intend to upload to your production server

They let you:

Download build results
Share files between jobs
Debug failures later

In other words:

“We worked hard on this — don’t throw it away.”

The Full CI/CD Story

Putting it all together:

You push code (event)
A workflow starts
The workflow creates jobs
Jobs run on a runner
Jobs execute steps
Steps produce artifacts
Everything runs automatically

That’s CI/CD.

Why This Matters

CI/CD gives you:

Faster feedback
Fewer production bugs
Less manual work
More confidence when shipping code

Instead of wondering:

“Did I forget to run something?”

You let the system handle it.

Final Thought

CI/CD isn’t about complexity — it’s about trusting automation to do the repeatable work better than humans.

Once you understand workflows, events, jobs, steps, runners, and artifacts, you already understand the foundation of modern CI/CD.

The rest is just details.

Building Definition Bot: Thinking Simple, Building Smart

Raji Sherifdeen ayinla — Wed, 05 Nov 2025 02:23:13 +0000

As part of the HNG Internship, The stage 3 task for backend was to build AI agents, So I decided to take on something small but meaningful — a project that would stretch my creativity, logic, and ability to ship something functional in a short time. That’s how Definition Bot was born.

The Idea

The idea behind Definition Bot is simple:

Type a word, and the bot instantly gives you its definition.

No distractions, no complex commands — just quick, helpful definitions.

I’ve always believed that simplicity is powerful. You don’t have to reinvent the wheel to learn or build something impactful. The goal of this project was to keep things minimal yet purposeful — focusing more on clean logic and easy usability rather than heavy architecture.

The Tech

The bot is built entirely with TypeScript, ensuring strong typing, better structure, and maintainable code.

To power the AI side of the bot, I experimented with Mastra AI, which made handling definitions and language understanding smoother. It’s a lightweight integration that adds a layer of intelligence without complicating the setup.

By combining simple logic with a touch of AI, Definition Bot can respond quickly and accurately to definition requests — all while being open, transparent, and easy to extend.

Why It Matters

This project wasn’t just about building a bot — it was about learning how to think.

As developers, we often chase complexity, but during the HNG internship, I’ve realized that thinking simple often leads to better solutions. It’s about focusing on the user’s need and removing unnecessary noise.

Check it Out

You can explore the code, contribute, or try it out
Here:

Closing Thoughts

Definition Bot may be a small project, but it represents a bigger mindset — start small, think clearly, and build with purpose.

Every big step starts with a simple idea, and for me, this was one of those steps.
Here’s to learning, building, and growing through HNG