API Security ও OWASP Top 10
- ●OWASP Top 10 হলো সবচেয়ে গুরুতর ও ঘন ঘন ঘটা ওয়েব/API নিরাপত্তা ঝুঁকির তালিকা।
- ●Broken Access Control ও Injection আজকের সবচেয়ে সাধারণ ও বিপজ্জনক দুর্বলতা।
- ●Rate limiting, input validation, ঠিকঠাক CORS ও secrets management API রক্ষায় অপরিহার্য।
সমস্যাটা কী?
তোমার API হলো বাইরের জগতের সাথে অ্যাপের দরজা। কিন্তু এই দরজা দিয়ে শুধু বৈধ ইউজার নয়, হাজার হাজার বট, স্ক্যানার আর আক্রমণকারীও কড়া নাড়ে। একটা ছোট ভুল— যেমন ইউজার-ইনপুট সরাসরি query-তে বসিয়ে দেওয়া, বা একটা endpoint-এ permission চেক ভুলে যাওয়া— পুরো database ফাঁস করে দিতে পারে।
সমস্যা হলো নিরাপত্তা ঝুঁকি এত রকম যে নতুন ডেভেলপার বুঝে উঠতে পারে না কোথা থেকে শুরু করবে। এখানেই OWASP-এর Top 10 কাজে আসে— এটি গবেষণা-ভিত্তিক একটি তালিকা যা বলে দেয় সবচেয়ে বেশি ক্ষতি কোন কোন ঝুঁকি থেকে হয়, তাই কোথায় আগে মনোযোগ দিতে হবে।
মূল ধারণা
OWASP Top 10 হলো Open Worldwide Application Security Project-এর প্রকাশিত একটি তালিকা, যেখানে সবচেয়ে প্রচলিত ও গুরুতর ১০টি ওয়েব/API নিরাপত্তা ঝুঁকি স্থান পায়। এটি কোনো বাধ্যতামূলক নিয়ম নয়, বরং সচেতনতা ও অগ্রাধিকারের গাইড।
API security-র মূল দর্শন হলো— কোনো input-কেই বিশ্বাস করো না এবং least privilege মেনে চলো (যতটুকু দরকার ঠিক ততটুকু অ্যাক্সেস)। প্রতিটি request যাচাই করো: কে পাঠাচ্ছে (auth), তার কি অনুমতি আছে (access control), এবং ডেটাটা কি বৈধ (validation)।
কীভাবে কাজ করে
প্রধান কয়েকটি ঝুঁকি
| ঝুঁকি | কী ঘটে | প্রতিকার |
|---|---|---|
| Injection | ইনপুট কোড হিসেবে চলে যায় | parameterized query |
| Broken Access Control | অনুমতি ছাড়াই অ্যাক্সেস | প্রতি request-এ authz চেক |
| Broken Authentication | দুর্বল লগইন/session | strong auth, MFA |
| Security Misconfiguration | ডিফল্ট/খোলা সেটিং | hardening, কম permission |
| Sensitive Data Exposure | ডেটা encrypt নয় | TLS + at-rest encryption |
Injection
সবচেয়ে পুরোনো অথচ এখনো ভয়ংকর ঝুঁকি। ইউজারের দেওয়া ডেটা যদি সরাসরি SQL query বা command-এ বসিয়ে দাও, আক্রমণকারী সেখানে নিজের কোড ঢুকিয়ে দিতে পারে।
// বিপজ্জনক
"SELECT * FROM users WHERE id = " + userInput
// নিরাপদ (parameterized)
"SELECT * FROM users WHERE id = ?" + [userInput]
দ্বিতীয় উপায়ে input কখনো কোড হিসেবে গণ্য হয় না, শুধু ডেটা— তাই Injection অসম্ভব।
Broken Access Control
বর্তমান OWASP তালিকার শীর্ষ ঝুঁকি। উদাহরণ— /api/orders/123-এ তুমি লগইন কিনা দেখলে, কিন্তু order 123 আসলে এই ইউজারের কিনা না দেখলে। তখন যে কেউ ID বদলে অন্যের ডেটা দেখবে (একে বলে IDOR)। প্রতিকার— প্রতিটি সংবেদনশীল কাজে ownership ও permission যাচাই। এটি Broken Access Control।
API security অনেকটা বিমানবন্দরের নিরাপত্তার মতো। বোর্ডিং পাস চেক করা হলো authentication, নির্দিষ্ট গেটেই ঢুকতে দেওয়া হলো access control, ব্যাগ স্ক্যান করা হলো input validation, আর একই লোক বারবার লাইনে দাঁড়ালে আটকানো হলো rate limiting। যেকোনো একটি ধাপ বাদ দিলেই পুরো নিরাপত্তা ভেঙে পড়ে— সব স্তর একসাথে কাজ করে।
কৌশল
Rate limiting
নির্দিষ্ট সময়ে একজন ক্লায়েন্ট কতবার request করতে পারবে তা সীমিত করা— যেমন মিনিটে ১০০ বার। এটি brute-force লগইন, scraping ও DoS অপব্যবহার ঠেকায়। Rate Limiting সাধারণত IP, API key বা ইউজার-প্রতি প্রয়োগ করা হয়।
Input validation
প্রতিটি input-এর type, length, format কঠোরভাবে যাচাই করো— allowlist (যা অনুমোদিত শুধু তা গ্রহণ) পদ্ধতি সবচেয়ে নিরাপদ। শুধু front-end validation যথেষ্ট নয়, কারণ আক্রমণকারী সরাসরি API কল করতে পারে; তাই সবসময় server-side validation করো।
CORS
CORS (Cross-Origin Resource Sharing) নিয়ন্ত্রণ করে কোন কোন origin (ওয়েবসাইট) তোমার API browser থেকে কল করতে পারবে। ভুল করে Access-Control-Allow-Origin: * দিলে যেকোনো সাইট তোমার API ব্যবহার করবে— সংবেদনশীল API-তে এটি বিপজ্জনক। শুধু বিশ্বস্ত origin allow করো।
API key ও Secrets management
API Key দিয়ে চেনা যায় কোন অ্যাপ request পাঠাচ্ছে এবং তার usage track ও সীমিত করা যায়। তবে key, password, token-এর মতো গোপন তথ্য কখনো কোডে বা Git-এ রাখা যাবে না— এগুলো Secrets Management টুলে (যেমন Vault, AWS Secrets Manager, environment variable) রাখতে হয় এবং নিয়মিত rotate করতে হয়।
কখন ব্যবহার করবে / করবে না
প্রতিটি public API-তে অন্তত— authentication, প্রতি-endpoint authorization, input validation, rate limiting ও HTTPS রাখো। ছোট internal API-তেও "ভেতরের নেটওয়ার্ক নিরাপদ" ধরে নিয়ে চেক বাদ দিও না (zero trust)।
বিস্তারিত error message বাইরে দেখিও না— stack trace বা SQL error আক্রমণকারীকে তোমার সিস্টেমের ভেতরের তথ্য দিয়ে দেয়। আবার Allow-Origin: * ব্যবহার, কোডে hardcoded secret, বা front-end-only validation— এই তিনটি খুবই সাধারণ অথচ মারাত্মক ভুল। কখনোই নয়।
বাস্তব উদাহরণ
২০২১ সালে এক বড় সোশ্যাল প্ল্যাটফর্ম থেকে কোটি কোটি ইউজারের ফোন নম্বর scrape হয়— মূল কারণ ছিল একটি endpoint-এ যথাযথ rate limiting ও access control না থাকা; আক্রমণকারীরা বিপুল contact API কল করে ডেটা জুড়ে ফেলে। বিপরীতে Stripe-এর মতো প্রতিষ্ঠান API security-তে আদর্শ— strict API key, প্রতি-অ্যাকাউন্ট scope, আক্রমণাত্মক rate limiting এবং secret rotation দিয়ে তারা billions of dollars-এর লেনদেন রক্ষা করে।
ইন্টারভিউতে "তুমি একটা API কীভাবে নিরাপদ করবে?" জিজ্ঞেস করলে স্তরে স্তরে উত্তর দাও: "Authentication → প্রতি-endpoint authorization → input validation → rate limiting → HTTPS → secrets management।" সাথে OWASP-এর শীর্ষ ঝুঁকি Broken Access Control ও Injection উল্লেখ করলে তুমি আপডেটেড আছ বলে প্রমাণ হবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. OWASP Top 10 আসলে কী?
2. SQL injection ঠেকানোর সবচেয়ে কার্যকর উপায় কোনটি?
3. Rate limiting মূলত কোন ধরনের আক্রমণ ঠেকায়?