Welcome to my little digital corner...
The AppSec Journal, my personal lab, studio, and story all in one.
Think of it as a quiet cozy desk glowing softly under LED light — a space where code hums gently, security breathes naturally, and every idea gets a moment to grow without hurry.
This isn’t a corporate blog or a lecture hall. It’s a workspace for wonder. A small, quiet world where I experiment, break things, fix them again, and write down what I’ve learned in a language that feels human.
Here, I build apps, test vulnerabilities, explore frameworks, and connect the dots between security and creativity. Because to me, secure software isn’t just about defense — it’s about craftsmanship, care, and clarity.
I believe learning should feel warm and personal — not a checklist, not a race. So I take my time here. I write slowly, build carefully, and share openly.
In here you will find...
Deep dives into web and mobile security. Other times, it is reflections, experiments, or quiet musings about what it means to build software that people can trust.
This journal is where I think out loud. Where code, design, and faith in better systems all come together. Where the technical meets the thoughtful — and where I can be both the developer and the dreamer.
#WorkspacePhilosophy
The Core Technology Stacks
Let us take a quick look at the list of the major technologies powering The AppSec Journal:
MDX
Next.js
React
shadcn/ui
Tailwind CSS
TypeScript
It began with words — the kind that live in Markdown files, simple and serene.
We wrote with rhythm, with meaning, with order. But Markdown was static.
It couldn’t react, couldn’t respond, couldn’t whisper back.
Then, one evening, as the codebase of The AppSec Journal grew deeper and more expressive,
we found ourselves craving something that could breathe.
Something that could hold text, yet also hold life.
And that’s when we met MDX — the hybrid dreamer of Markdown and React.
It didn’t ask us to choose between clarity and capability.
It simply said: “Why not both?”
🧭 Why MDX felt right for The AppSec Journal
The AppSec Journal isn’t just a site — it’s a voice, a living record of ideas where security meets storytelling.
We needed a way to merge technical precision with editorial warmth,
to write lessons and insights that felt alive, interactive, and yet secure.
MDX gave us that bridge.
It lets us write in Markdown’s comfort — headers, lists, emphasis —
while seamlessly sprinkling in React components from our shadcn/ui library.
That means our words can flow naturally,
and our interface can demonstrate what we’re teaching — all in one file.
A concept explained in text can be instantly supported by a live example, a styled component,
or even a secure code snippet rendered safely through sandboxed components.
🌿 Harmony with Next.js and shadcn/ui
Next.js gives us the architecture —
server-rendered, performant, and secure foundations that treat MDX files like first-class citizens.
Every .mdx file is compiled and optimized just like any other React component,
so we keep the balance between content and computation.
shadcn/ui, on the other hand, brings beauty and consistency.
It’s clean, minimal, and accessible —
allowing MDX pages to look polished without compromising performance or security.
We can use components like <Card>, <Tabs>, and <Alert> directly within the story,
turning lessons into interactive experiences that feel handcrafted and safe.
Together, they form a trinity:
- Next.js — the secure foundation.
- shadcn/ui — the visual voice.
- MDX — the storyteller’s heart.
🛡️ A Note on Security
MDX is powerful, and with great power comes the familiar whisper: “Be careful.”
When content can include React, it also means the potential for unsafe injections or dynamic imports.
That’s why, at AppSec Journal, we follow strict hygiene practices:
- We sanitize and validate all dynamic MDX content before rendering.
- We disable arbitrary HTML in Markdown unless trusted.
- We scope our components — only exposing safe, pre-approved ones to the MDX renderer.
- We audit imports and components to prevent cross-site scripting (XSS) vulnerabilities.
- We run MDX through build-time compilation instead of serving raw input.
In short, our MDX is expressive — but disciplined.
Creativity thrives best when the boundaries are secure.
🌍 Why not other systems?
We looked around — at CMS platforms, headless editors, and static site generators.
Each had charm, but also chains.
They either slowed down our workflow, locked us into rigid interfaces,
or demanded we surrender too much control over rendering and security.
Chakra UI, while beautiful, felt a bit heavy for our use case.
Other content systems blurred the developer–writer boundary too much.
We didn’t want separation between code and content; we wanted collaboration.
MDX offered the most honest solution:
write your thoughts, style them as components, and render them safely —
all within the same creative space.
✨ In the End
MDX made writing feel like crafting again.
Every paragraph became a component, every component a brushstroke.
It fits The AppSec Journal because it’s not just about displaying text —
it’s about telling stories that teach security with life, motion, and clarity.
Here, content isn’t just written.
It’s compiled, secured, and shared —
so every idea we publish stands both artistically beautiful and technically sound.
MDX reminds us that great storytelling and great security aren’t opposites.
They’re two halves of the same truth —
clarity with care, knowledge with protection, beauty with boundaries.
Markdown + JSX for secure content
It began with words — the kind that live in Markdown files, simple and serene.
We wrote with rhythm, with meaning, with order. But Markdown was static.
It couldn’t react, couldn’t respond, couldn’t whisper back.
Then, one evening, as the codebase of The AppSec Journal grew deeper and more expressive,
we found ourselves craving something that could breathe.
Something that could hold text, yet also hold life.
And that’s when we met MDX — the hybrid dreamer of Markdown and React.
It didn’t ask us to choose between clarity and capability.
It simply said: “Why not both?”
🧭 Why MDX felt right for The AppSec Journal
The AppSec Journal isn’t just a site — it’s a voice, a living record of ideas where security meets storytelling.
We needed a way to merge technical precision with editorial warmth,
to write lessons and insights that felt alive, interactive, and yet secure.
MDX gave us that bridge.
It lets us write in Markdown’s comfort — headers, lists, emphasis —
while seamlessly sprinkling in React components from our shadcn/ui library.
That means our words can flow naturally,
and our interface can demonstrate what we’re teaching — all in one file.
A concept explained in text can be instantly supported by a live example, a styled component,
or even a secure code snippet rendered safely through sandboxed components.
🌿 Harmony with Next.js and shadcn/ui
Next.js gives us the architecture —
server-rendered, performant, and secure foundations that treat MDX files like first-class citizens.
Every .mdx file is compiled and optimized just like any other React component,
so we keep the balance between content and computation.
shadcn/ui, on the other hand, brings beauty and consistency.
It’s clean, minimal, and accessible —
allowing MDX pages to look polished without compromising performance or security.
We can use components like <Card>, <Tabs>, and <Alert> directly within the story,
turning lessons into interactive experiences that feel handcrafted and safe.
Together, they form a trinity:
- Next.js — the secure foundation.
- shadcn/ui — the visual voice.
- MDX — the storyteller’s heart.
🛡️ A Note on Security
MDX is powerful, and with great power comes the familiar whisper: “Be careful.”
When content can include React, it also means the potential for unsafe injections or dynamic imports.
That’s why, at AppSec Journal, we follow strict hygiene practices:
- We sanitize and validate all dynamic MDX content before rendering.
- We disable arbitrary HTML in Markdown unless trusted.
- We scope our components — only exposing safe, pre-approved ones to the MDX renderer.
- We audit imports and components to prevent cross-site scripting (XSS) vulnerabilities.
- We run MDX through build-time compilation instead of serving raw input.
In short, our MDX is expressive — but disciplined.
Creativity thrives best when the boundaries are secure.
🌍 Why not other systems?
We looked around — at CMS platforms, headless editors, and static site generators.
Each had charm, but also chains.
They either slowed down our workflow, locked us into rigid interfaces,
or demanded we surrender too much control over rendering and security.
Chakra UI, while beautiful, felt a bit heavy for our use case.
Other content systems blurred the developer–writer boundary too much.
We didn’t want separation between code and content; we wanted collaboration.
MDX offered the most honest solution:
write your thoughts, style them as components, and render them safely —
all within the same creative space.
✨ In the End
MDX made writing feel like crafting again.
Every paragraph became a component, every component a brushstroke.
It fits The AppSec Journal because it’s not just about displaying text —
it’s about telling stories that teach security with life, motion, and clarity.
Here, content isn’t just written.
It’s compiled, secured, and shared —
so every idea we publish stands both artistically beautiful and technically sound.
MDX reminds us that great storytelling and great security aren’t opposites.
They’re two halves of the same truth —
clarity with care, knowledge with protection, beauty with boundaries.