https://www.fahimahammed.me/, https://www.youtube.com/@fahim-ahammed-firoz

Fahim Ahammed Firoz, Bhurungamari, Canada, KY (2026)

04/22/2026

Vercel Hacked. এটা ছিল একটা supply chain + account takeover ঘটনা।

এটা সরাসরি Vercel-এর infrastructure ভাঙা কোনো attack না। বরং এটা ছিল একটা supply chain attack + identity compromise chain।

ঘটনার শুরু হয় Context AI নামের একটি third-party tool থেকে, যেটা একজন Vercel employee ব্যবহার করছিলেন। ওই টুলটি compromise হওয়ার পর attacker সেই employee’র Google Workspace account access নিতে সক্ষম হয়।

Google Workspace-এর মাধ্যমে attacker-এর হাতে শুধু email বা docs না, বরং পুরো identity layer চলে আসে। আর এই identity access দিয়েই internal systems-এর দিকে যাওয়ার সুযোগ তৈরি হয়। এখান থেকেই risk শুরু হয় Vercel-এর internal environment, deployment-related data এবং connected services নিয়ে।

এর মানে হলো, এক জায়গায় বিশ্বাস (third-party tool + OAuth permission) ভুলভাবে দেওয়া হলে পুরো security chain ভেঙে যেতে পারে।

সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো: sensitive secrets হয়তো সরাসরি exposed হয়নি, কিন্তু non-sensitive environment variables এবং metadata exposure-এর কারণে অনেকেই ঝুঁকিতে পড়ে যেতে পারে। কারণ বাস্তবে অনেক dev ভুল করে API key বা token এই non-sensitive জায়গাতেই রেখে দেয়।

AI tools বা third-party integrations blindly trust করা যাবে না।

- যেকোনো AI tool install করার আগে source এবং permission model বুঝতে হবে
- OAuth access মানে অনেক সময় full account access হয়ে যেতে পারে
- Environment variables properly classify করা জরুরি (sensitive vs non-sensitive)
- Principle of least privilege follow না করলে একটি account থেকেই বড় damage হতে পারে
- Unofficial tools বা unknown distribution ব্যবহার করা risky.

মূল কথা হলো, সমস্যা শুধু একটি কোম্পানির না, এটা আধুনিক developer ecosystem-এর security discipline-এর সমস্যা।

AI এবং automation যত বাড়ছে, ততই আমাদের access control, permission এবং secret management আরও strict হতে হবে।

সাবধানে থাকুন, বুঝে tools ব্যবহার করুন।

04/11/2026

সম্প্রতি Axios নিয়ে একটি বড় ধরনের supply chain attack ধরা পড়েছে, যা প্রতিটি developer-এর জন্য গুরুত্বপূর্ণ একটি শিক্ষা।

Joe Desimone দেখিয়েছেন কীভাবে একটি simple AI-powered proof of concept tool, যেটি তিনি মাত্র এক বিকেলে তৈরি করেছিলেন, real-time এ এই compromise detect করতে পেরেছে। এই tool টি নতুন package release monitor করত, পুরোনো ও নতুন version-এর মধ্যে diff করত, এবং তারপর একটি LLM ব্যবহার করে যাচাই করত পরিবর্তনটি malicious কিনা।
এই attack টি ছিল বেশ কৌশলী। সরাসরি Axios-এর মূল code পরিবর্তন করা হয়নি। এর পরিবর্তে একটি malicious dependency যুক্ত করা হয়েছিল, যা install হওয়ার সময় গোপনে harmful code execute করত। অর্থাৎ, একজন developer একটি trusted package install করলেও অজান্তেই তার system বা CI pipeline আক্রান্ত হতে পারত।

এই ঘটনাটি একক কোনো ঘটনা ছিল না। এর আগে Trivy, LiteLLM, এবং Telnyx Python SDK-এর মতো tools গুলোও compromise হয়েছিল। চুরি হওয়া credentials এবং দ্রুত response না থাকার কারণে এই attack ধাপে ধাপে আরও ছড়িয়ে পড়ে।

এখানে কয়েকটি গুরুত্বপূর্ণ বিষয় আমাদের মাথায় রাখা দরকার।

প্রথমত, dependency-এর উপর blind trust করা এখন আর নিরাপদ নয়। জনপ্রিয় এবং widely used package-ও attack-এর মাধ্যম হতে পারে।

দ্বিতীয়ত, নতুন version release হওয়ার সাথে সাথেই update করা ঝুঁকিপূর্ণ হতে পারে। কিছুটা delay রাখা ভালো, যাতে community আগে সম্ভাব্য সমস্যা detect করতে পারে।

তৃতীয়ত, AI এখন security ক্ষেত্রে একটি গুরুত্বপূর্ণ ভূমিকা রাখতে শুরু করেছে। code change analyse করে দ্রুত suspicious behavior শনাক্ত করা এখন আগের চেয়ে অনেক সহজ।

এই ঘটনাটি আমাদের মনে করিয়ে দেয় যে modern software ecosystem অত্যন্ত interconnected। তাই শুধু code লেখা নয়, dependency management এবং security practice নিয়েও সচেতন হওয়া জরুরি।

ecosystem পরিবর্তন হচ্ছে। আমাদের কাজ করার ধরণও সেই অনুযায়ী পরিবর্তন করতে হবে।

Axios team already compromised versions identify করে remove করেছে এবং issue fix করেছে। দ্রুত response এর কারণে potential damage অনেকটাই কমানো সম্ভব হয়েছে।

03/02/2026

SQL Injection- যখন Input হয় Attack Vector

Web application তৈরি করার সময় আমরা form বানাই, login system বানাই, search feature বানাই। কিন্তু একটি ছোট ভুল input handling পুরো database expose করে দিতে পারে। এই attack technique টার নাম SQL Injection।

ধরুন আপনি একটি office reception এ গেলেন। Receptionist আপনাকে জিজ্ঞেস করলো, আপনার নাম বলুন, আমি list এ check করছি।
- আপনি বললেন, Fahim।
- কিন্তু যদি কেউ বলে, Fahim or everyone in the list
- আর receptionist যদি সেই কথাটাই সরাসরি system এ লিখে search করে, তাহলে পুরো list open হয়ে যেতে পারে।

SQL Injection ঠিক এমনই। User input যদি blindly database query তে যোগ করা হয়, তাহলে attacker নিজের query inject করতে পারে

SQL Injection হলো এমন একটি attack যেখানে attacker malicious SQL code user input এর মাধ্যমে database query এর ভিতরে inject করে। যদি query properly sanitize বা parameterized না হয়, তাহলে attacker:
• Login bypass করতে পারে
• Sensitive data extract করতে পারে
• Database modify করতে পারে
• Table delete পর্যন্ত করতে পারেএকটি সাধারণ vulnerable উদাহরণ

ধরুন backend এ query এমন:
SELECT * FROM users WHERE email = 'user_input' AND password = 'user_input';

যদি attacker password field এ লিখে:
' OR 1=1 --
তাহলে query logic বদলে যায়।
- Condition সবসময় true হয়ে যেতে পারে।
- Login bypass হয়ে যেতে পারে

কারণ database হলো application এর core asset। User data, payment info, business data সবই সেখানে থাকে।
একটি SQL Injection vulnerability মানে পুরো system compromise হওয়ার ঝুঁকি।

SQL Injection prevent করা সম্ভব যদি কিছু best practice follow করা হয়।
1. Parameterized Query বা Prepared Statement ব্যবহার করুন। User input কখনো direct string concatenation দিয়ে query তে যোগ করবেন না।
2. ORM ব্যবহার করুন। Modern ORM গুলো default ভাবে parameterized query ব্যবহার করে।
3. Input Validation. Unexpected character বা malicious pattern filter করুন।
4. Least Privilege Principle. Database user কে minimum required permission দিন।
5. Application user দিয়ে DROP TABLE permission দেবেন না।

Security পরে add করার বিষয় না। Design phase থেকেই secure coding practice adopt করা প্রয়োজন। User input সবসময় untrusted। Trust করা যাবে না, validate করতে হবে।

03/01/2026

Clickjacking: When Your User Clicks, But Not Where They Think

Web security নিয়ে কথা বললে আমরা সাধারণত SQL Injection, XSS, brute force নিয়ে ভাবি।
কিন্তু একটি silent এবং dangerous attack আছে যা purely user perception exploit করে।
তার নাম Clickjacking... একটি simple real life analogy
ধরুন আপনি একটি document এ sign করছেন।
উপরে বড় করে লেখা আছে One Time Donation Authorization।
আপনি ভালো উদ্দেশ্যে sign করলেন।
কিন্তু document এর উপরে একটি transparent paper layer ছিল।
নিচের আসল document এ লেখা ছিল Recurring Monthly Auto Debit Agreement।
আপনি sign করেছেন।
কিন্তু যা দেখেছেন, সেটাই পুরো সত্য ছিল না।

Clickjacking ঠিক এইরকম visual deception।
Clickjacking হলো এমন একটি attack যেখানে attacker আপনার website কে hidden iframe এর ভিতরে load করে এবং তার উপর fake UI overlay বসায়।
User ভাবে সে একটি harmless button এ click করছে।
কিন্তু background এ sensitive action execute হয়ে যায়।
এটাকে UI Redressing attack ও বলা হয়।

এটি কীভাবে কাজ করে--
1. Attacker একটি malicious webpage তৈরি করে
2. সেখানে target website কে iframe এ load করে
3. iframe কে transparent বা invisible করে
4. তার উপর attractive button বসায়
5. User click করে
6. Background এ original website এ action trigger হয়।

Server side থেকে request valid মনে হয়।
কারণ click user নিজেই করেছে।

Clickjacking দিয়ে attacker পারে:
• Account settings change করতে
• Email update করতে
• Password reset trigger করতে
• Payment confirm করাতে
• Admin level action execute করাতে

সবচেয়ে বড় সমস্যা হলো
এটি user trust exploit করে।

Clickjacking prevent করা খুবই straightforward যদি আপনি proper headers configure করেন।
1. X Frame Options
Set করুন: X Frame Options: DENY অথবা, X Frame Options: SAMEORIGIN
2. Content Security Policy Use করুন:
Content Security Policy: frame ancestors 'none';
Modern browsers এ এটি recommended approach।

Web security শুধু backend validation না। Browser level protection equally critical। User যা দেখছে এবং যেখানে click করছে, সেটি যেন actual target হয় তা নিশ্চিত করা developer এর দায়িত্ব।

02/23/2026

আপনি কি ভেবেছেন, কিভাবে Stripe এক সেকেন্ডের ভেতর মিলিয়ন মিলিয়ন ট্রানজ্যাকশন হ্যান্ডেল করতে পারে এবং 99.99% uptime ধরে রাখতে পারে? এটা শুধু শক্তিশালী সার্ভার থাকার কারণে নয়, এটা তাদের সঠিক আর্কিটেকচার, ডেটা কনসিস্টেন্সি এবং failure-aware ডিজাইনের ফল।

Stripe-এর smooth এক্সপেরিয়েন্স মূলত কয়েকটি গুরুত্বপূর্ণ সিদ্ধান্তের কারণে তৈরি হয়:

1. Reliability-First Architecture
Stripe এমনভাবে ডিজাইন করেছে যে কোনো একটি সার্ভার বা ডাটা সেন্টার ডাউন হলেও পুরো সিস্টেম বন্ধ হবে না। Multiple region, smart load balancing এবং automatic failover ব্যবহার করে, কোনো সমস্যা হলে ট্রাফিক seamlessভাবে অন্য জায়গায় চলে যায়। ইউজার কখনো বুঝতে পারে না পেছনে কী ঘটছে।

2. Idempotency এবং ডেটা কনসিস্টেন্সি
ইন্টারনেট স্লো হলে বা ইউজার ভুলবশত দুইবার ক্লিক করলে ডুপ্লিকেট রিকোয়েস্ট আসে। Stripe প্রতিটি রিকোয়েস্টকে একটি ইউনিক Idempotency Key দিয়ে চিহ্নিত করে। একই রিকোয়েস্ট বারবার এলে সার্ভার বুঝে ফেলে এটি আগে প্রসেস হয়েছে। ফলে ডুপ্লিকেট চার্জ হয় না এবং ব্যবহারকারীর trust ধরে থাকে।

3. Smart API Versioning
অনেক কোম্পানি নতুন API ভার্সন আনার সময় পুরনো integration ভেঙে দেয়। Stripe তা হতে দেয় না। Transformation layer ব্যবহার করে পুরনো রিকোয়েস্টকে নতুন সিস্টেমের সাথে মিলিয়ে দেয়। তাই ৮–১০ বছর আগের কোডও আজও ঠিকমতো কাজ করে।

4. Webhooks এবং Intelligent Retry
যদি পেমেন্ট সফল হয় কিন্তু সার্ভার তখন ডাউন থাকে, Stripe থেমে যায় না। তারা বারবার webhook পাঠায় যতক্ষণ না সফল response পাওয়া যায়। Consistency speed-এর চেয়ে বেশি গুরুত্বপূর্ণ তাদের জন্য।

5. Developer Experience
Clean API, অসাধারণ documentation এবং predictable error handling ডেভেলপারদের জন্য integration friction কমায়। ডেভেলপার ভুল কম করলে পুরো সিস্টেমও বেশি stable থাকে, আর ব্যবহারকারীর experience smooth হয়।

Stripe সবসময় “design for failure” দর্শনে বিশ্বাস করে। তারা জানে failure আসবেই, তাই সিস্টেম এমনভাবে তৈরি করে যে ইউজার কখনো তার মাশুল না দেয়। Smoothness মানে শুধু দ্রুততা নয়। এটি predictability, reliability এবং trust।

02/18/2026

Ramadan Mubarak 🌙

May this holy month light up our hearts just like this lantern -bringing peace, forgiveness, and countless blessings into our lives.

May Allah accept our fasting and prayers 🤍

02/16/2026

Backend বা API development করতে গেলে আমরা authentication, authorization, database optimization নিয়ে অনেক কথা বলি। কিন্তু production এ application secure এবং stable রাখতে Rate Limiting জানা অত্যন্ত জরুরি।

Rate limiting হলো একটি technique যার মাধ্যমে নির্দিষ্ট সময়ের মধ্যে একজন user, একটি IP, বা একটি client কতগুলো request করতে পারবে তা নির্ধারণ করা হয়।

For example,
ধরুন আপনার একটি public API আছে। কেউ যদি খুব অল্প সময়ে হাজার হাজার request পাঠায়, তাহলে server slow হয়ে যেতে পারে বা crash করতে পারে। Rate limiting সেই অতিরিক্ত request block করে system কে safe রাখে।

কেন Rate Limiting Important?
1. অতিরিক্ত load থেকে server কে রক্ষা করে
2. অনিয়ন্ত্রিত request flood হলে limit করে impact কমানো যায়
3. একজন user যেন সব resource ব্যবহার করে অন্যদের জন্য system slow না করে
4. Cloud infrastructure ব্যবহার করলে অতিরিক্ত traffic মানে extra cost.

Fixed Window Rate Limiter
- নির্দিষ্ট একটি সময়ের window যেমন ১ মিনিটে ১০০ request allow করা হয়।
- সময় শেষ হলে counter reset হয়।
- Implement করা সহজ, তবে window boundary সমস্যা থাকতে পারে।

Sliding Window Rate Limiter
- Fixed window এর limitation কমাতে ব্যবহার করা হয়।
- সময় অনুযায়ী request count smooth ভাবে shift হয়, ফলে sudden burst problem কমে।

Token Bucket Rate Limiter
- একটি bucket এ নির্দিষ্ট rate এ token জমা হয়।
- প্রতিটি request একটি token ব্যবহার করে।
- Burst traffic handle করতে খুব কার্যকর।

Session Based Rate Limiting
- IP based না করে authenticated user বা session অনুযায়ী limit করা হয়।
- SaaS বা multi user system এ এটি বেশি কারএকজন backend developer হিসেবে

শুধু middleware ব্যবহার করলেই হবে না।
Algorithm কিভাবে কাজ করে, কোথায় কোনটি ব্যবহার করা উচিত, এবং তাদের trade off কী তা বোঝা প্রয়োজন।

Scalable এবং secure application বানাতে চাইলে Rate Limiting অবশ্যই জানা উচিত একটি বিষয়।

Comment এ দেওয়া link থেকে Rate Limiting এবং Fixed Window Rate Limiting সম্পর্কে theory এবং practical শিখতে পারবেন।

02/13/2026

Recently Google Cloud তাদের Cloud Observability stack এ একটি গুরুত্বপূর্ণ update ঘোষণা করেছে।

তারা একটি নতুন OpenTelemetry ingestion API চালু করেছে যার endpoint হলো telemetry.googleapis.com। এটি native OTLP logs, trace spans এবং metrics support করে। অর্থাৎ এখন observability data একটি unified endpoint এর মাধ্যমে handle করার দিকে তারা এগোচ্ছে।

March 23, 2026 থেকে যখন নিচের যেকোনো ingestion API enable করা থাকবে
- logging.googleapis.com
- cloudtrace.googleapis.com
- monitoring.googleapis.com

তখন নতুন telemetry.googleapis.com automatic dependency হিসেবে enable হয়ে যাবে।

যেসব existing project এ ইতিমধ্যে এই APIs গুলো active আছে, সেগুলোতেও Google automaticভাবে নতুন endpoint enable করে দেবে। কোনো manual action প্রয়োজন নেই এবং existing service এ কোনো disruption হবে না।

OpenTelemetry এখন industry standard হয়ে উঠছে distributed system এ logs, metrics এবং traces collect করার জন্য। Google Cloud ধীরে ধীরে তাদের ingestion architecture কে unified এবং cloud native standard এর সাথে align করছে।

যারা backend, microservices, DevOps বা production workload নিয়ে কাজ করি, তাদের জন্য এই ধরনের platform level change সম্পর্কে aware থাকা জরুরি। সব update action required না হলেও ecosystem কোন দিকে যাচ্ছে সেটা জানা smart engineering decision নিতে সাহায্য করে।

Cloud silently evolve করে।
Prepared engineers সবসময় updated থাকে।

02/08/2026

ধরুন আপনি একটি দোকান চালান। দোকানে একসাথে নির্দিষ্ট সংখ্যক মানুষ ঢুকতে পারে। কিন্তু যদি হঠাৎ করে অনেক মানুষ একসাথে ঢুকে পড়ে, তাহলে দোকান সামলানো কঠিন হয়ে যাবে এবং সবার অভিজ্ঞতাই খারাপ হবে। সার্ভার বা API এর ক্ষেত্রেও বিষয়টা ঠিক একই। এখানেই Rate Limiting এর প্রয়োজন হয়।

Rate Limiting হলো একটি নিয়ম, যেখানে নির্দিষ্ট সময়ের মধ্যে একজন user বা একটি IP address সর্বোচ্চ কতগুলো request পাঠাতে পারবে তা limit করে দেওয়া হয়।

কেন Rate Limiting প্রয়োজন

Server protection
একই user বা bot যদি খুব অল্প সময়ের মধ্যে অনেক request পাঠায়, তাহলে সার্ভার overload বা crash করতে পারে। Rate limiting সার্ভারকে এই চাপ থেকে বাঁচায়।

Security ensure করে
Brute force attack, credential stuffing বা DDoS এর মতো আক্রমণ অনেকটাই কমানো যায়।

Fair usage বজায় রাখে
একজন user যেন সব resource একা ব্যবহার না করে ফেলে। সবাই যেন সমানভাবে service পায়।

Performance ভালো রাখে
Unnecessary request কম হলে genuine user দের জন্য response time ভালো থাকে।

Cost control
Cloud based infrastructure এ বেশি request মানেই বেশি খরচ। Rate limiting এই খরচ নিয়ন্ত্রণে সাহায্য করে।

Backend development বা system design শিখতে হলে Rate Limiting একটি basic কিন্তু খুবই গুরুত্বপূর্ণ concept। Production ready system বানাতে গেলে এটি ignore করার সুযোগ নেই।

02/03/2026

ব্যাকএন্ড ডেভেলপারদের জন্য লোড টেস্টিং একটি খুবই important step। শুধু কোড লিখলেই কিন্তু সব হয় না, আমাদের API বা সার্ভারের performance, stability এবং real-world user experience নিশ্চিত করতে হয়। এই জন্যই Load Testing প্রয়োজন। Load Testing হলো এমন একটি process যেখানে আমরা আমাদের API বা সার্ভারে simulated traffic চালাই যেন দেখা যায় কতজন concurrent users সিস্টেম use করতে পারবে, response time কেমন হবে, এবং কোথায় bottleneck বা slow endpoint আছে।

Load Testing-এর major benefits হলো – প্রথমে, এটি আমাদের সিস্টেমকে reliable এবং crash-proof রাখে। যদি হঠাৎ অনেক user আসে, তাহলে system ঠিকভাবে কাজ করছে কি না সেটি বুঝতে পারি। দ্বিতীয়ত, এটি performance optimization-এ সাহায্য করে; কোন endpoint ধীর, কোন query slow, বা কোন function heavy load handle করতে পারছে না সবই চিহ্নিত করা যায়। তৃতীয়ত, Load Testing scaling decisions-এ guide করে – কখন extra servers, caching, বা load balancer দরকার হতে পারে। এবং সবশেষে, এটি ensure করে যে users get a smooth and fast experience, যা user retention এবং satisfaction-এর জন্য critical।

Backend developer হিসেবে সহজে Load Testing করা সম্ভব কিছু popular tools দিয়ে। যেমন:

Postman Collection Runner: ছোট-scale load test করার জন্য খুব convenient।

k6: Modern, JS-based CLI tool যা virtual users দিয়ে API load test করা যায় এবং scripting ও automation-friendly।

Node.js script: Simple small-scale tests বা proof-of-concept-এর জন্য।

Load Testing করতে গিয়ে কিছু tip মাথায় রাখা জরুরি – প্রথমে small scale থেকে শুরু করা, ধীরে ধীরে concurrency বা request count increase করা। গুরুত্বপূর্ণ endpoints যেমন login, payment, data fetch, ইত্যাদি prioritize করা। সবসময় staging environment-এ পরীক্ষা করা, production-এ নয়। পাশাপাশি, CPU, memory, DB queries monitor করা যেন load-এর সময় কোথায় bottleneck হচ্ছে তা বুঝা যায়।

সুতরাং, Load Testing শুধু একটি test নয়, এটি আমাদের backend system কে real-world traffic-এর জন্য ready করে, performance issues ধরার আগে সমস্যা prevent করার একটা গুরুত্বপূর্ণ step। Backend developer হিসেবে এটা জানা এবং করা খুবই প্রয়োজন।

Fahim Ahammed Firoz

04/22/2026

04/11/2026

03/02/2026

03/01/2026

02/23/2026

02/18/2026

02/16/2026

02/13/2026

02/08/2026

02/03/2026

Address

Website

Alerts

Shortcuts

Share