Skip to content

0x1RIS

Security used to be the 2AM hobby The thing I did when everyone else was asleep - breaking web apps , mapping AD attack paths , writing exploits that nobody asked for Back then it was just curiosity spiraling into obsession

Somewhere along the line I realized the backend is where the real fight happens Now I build the systems I used to break , and that changes everything about how I write code

My Journey

Alias 0x1RIS , I'm a backend engineer who came up through the offensive security trenches Started in web application pentesting when I was supposed to be doing something else productive with my time , wormed through Active Directory , fell into binary exploitation , spent years learning exactly how systems fail by making them fail on purpose

The transition from security hobbyist to backend engineer wasn't a pivot - it was the natural evolution of someone who spent too long staring at other people's vulnerabilities and thought "I can build this better"

Every SQL injection I exploited taught me why parameterized queries aren't optional Every buffer overflow I studied taught me memory safety in ways no linter ever could Every AD attack path I mapped taught me exactly how authentication flows crumble under pressure

Breaking things for years teaches you how to build things that don't break That's the whole philosophy condensed

What I Do

I build backend systems APIs , databases , authentication flows , the infrastructure that makes applications actually work But I build them with a security-first lens that comes from having been on the other side of the fence - I've run the same attacks against production systems that I used to run against lab targets and I know exactly where the cracks form

Backend Engineering

Node.js and Next.js architecture , REST and GraphQL API design , database modeling across SQL and NoSQL , authentication implementations that don't crumble under pressure , system design that scales without introducing attack surface

Security Engineering

Threat modeling as a design-phase habit not an afterthought , secure-by-default architecture where security is embedded in how I structure code not bolted on at the end , auth flow hardening that survives actual abuse , input validation that doesn't just check types but checks intent

Automation & Tooling

I got tired of repeating the same recon steps manually so I automated them Built frameworks for reconnaissance , payload generation , network traffic management - every tool emerged from a real pain point , not a "wouldn't it be cool" fantasy

My Professional Creed

Methodology

I don't believe in security checklists I believe in understanding the system deeply enough to know where it hurts before anyone else finds out

  1. Deep Understanding First - Before I write a single line of code I need to understand the threat model , the data flow , the trust boundaries Architecture decisions made without context are guesses dressed up as expertise

  2. Build for the Attack You Can't See - The vulnerability you didn't consider is the one that gets you I design systems assuming the attacker knows more than I do about my own code - and I engineer for that reality

  3. Validate Relentlessly - Every input , every edge case , every state transition Paranoid engineering is the only engineering that survives in production

  4. Ship What Survives - Code that passes code review is table stakes Code that survives penetration testing is the actual minimum

Core Competencies

Web Application Security Full-spectrum testing from modern SPAs to REST and GraphQL APIs to microservice meshes , each attack surface has its own dumb implementation mistakes waiting to be exploited

Mobile Application Security Android reverse engineering , APK analysis , traffic interception , finding what developers tried to hide in client-side code thinking nobody would look

Network Security Infrastructure penetration testing at scale , where nmap stops being a port scanner and becomes a precision instrument when you learn to use it right

Cloud Security AWS and Azure audits , finding the configuration failures that let attackers walk right in through S3 buckets and IAM misconfigs

Tool Development Custom reconnaissance frameworks , payload generators , exploitation tooling - off-the-shelf never cuts it when you need something specific

Technical Arsenal

Programming Python is my go-to for automation and exploitation , JavaScript and Node.js for web testing , Bash for post-exploitation and system administration , Go when I need speed and concurrency , C and C++ for reverse engineering and binary analysis where the real fun lives

Security Tools Burp Suite Pro (when it doesn't crash mid-scan) , Metasploit , Empire , Nmap , Masscan , Nessus , Ghidra , IDA Pro , Radare2 , SQLmap , Gobuster , Pwntools - the usual suspects with the unusual configurations

Platforms Linux is home - ParrotOS , Kali , Ubuntu depending on the mood and the mission Windows Server when the target demands it , cloud across AWS , Azure , and GCP

Philosophy

Why Security-First Engineering Works

Most security issues aren't introduced during the security review They're introduced the moment an architect decides on a data model , an engineer chooses an authentication library , a developer writes the first route handler Security isn't a phase - it's embedded in every decision or it doesn't exist

I've seen the same vulnerabilities appear across a hundred different codebases , and the pattern is always the same Someone wasn't thinking about the attack when they made a design choice That's not a code problem - that's a mindset problem

Work Ethic

  • Write code that survives , not code that passes review
  • Understand the system before you try to secure it
  • Automate the boring shit but never skip thoroughness
  • If a tool saved me hours it'll save someone else too - open source by default
  • The attacker only needs to be right once , so the defender needs to be right every time

Profiles

Security research and engineering are what I do For the full picture - open-source projects , write ups , CTF profiles , and professional work - check the links

Started in the dark , built in the light , systems that survive both

For business inquiries and security consulting , reach out through LinkedIn

For technical discussions and open-source collaboration , GitHub issues and pull requests are the way

For vulnerability disclosures - encrypted communication preferred , security demands it

I'm available for security consulting , architecture reviews , and mentoring ambitious engineers who want to build the kind of systems that don't keep them up at night

Let's build things that survive