كيف تؤمن API الخاصة بك: من Authentication إلى Rate Limiting دون أن تفقد عقلك

في عام 2023 وحده، تعرضت أكثر من 60% من الشركات لهجمات على واجهات برمجة التطبيقات (APIs) وفقاً لتقرير شركة Akamai. المشكلة ليست في نقص الأدوات، بل في سوء استخدامها. كثير من المطورين يظنون أن إضافة مفتاح API (API Key) يكفي لجعل النظام آمناً، لكن الحقيقة أن هذا مجرد بداية. الهجمات الحديثة تستخدم تقنيات متقدمة مثل الـ Replay Attacks و الـ Credential Stuffing و الـ DDoS Layer 7 لاستغلال الثغرات في الـ Authentication و الـ Rate Limiting. إذا كنت تريد حماية API الخاص بك حقاً، عليك أن تفهم كيف تعمل هذه الهجمات على مستوى الـ Memory و الـ Network Stack، وليس فقط على مستوى الكود.

الخطأ الأكبر الذي أراه في المشاريع هو التعامل مع الأمان كطبقة إضافية تُضاف في النهاية. الأمان ليس طبقة، بل هو جزء لا يتجزأ من تصميم النظام منذ اليوم الأول. عندما تتجاهل المصادقة القوية أو الـ Rate Limiting حتى مرحلة الإنتاج، فأنت تفتح الباب أمام هجمات قد تدمر سمعتك التقنية خلال ساعات. في هذا المقال، سأريك كيف تبني نظاماً آمناً من الصفر، خطوة بخطوة، مع التركيز على التفاصيل التي غالباً ما تُهمل مثل الـ Token Rotation و الـ JWT Blacklisting و الـ Sliding Window Rate Limiting.

لماذا المصادقة البسيطة ليست كافية؟

الكثير من المطورين يبدأون بـ Basic Authentication أو مفاتيح API الثابتة (Static API Keys) ظناً منهم أنها كافية. المشكلة أن هذه الأساليب سهلة الاختراق. الـ Basic Auth يرسل بيانات الاعتماد كـ Base64 encoded، وهي ليست تشفيراً حقيقياً، ويمكن فك تشفيرها بسهولة باستخدام أي أداة مثل Burp Suite. أما مفاتيح API الثابتة فهي أسوأ، لأنها تبقى صالحة إلى الأبد ما لم تُغير يدوياً، وإذا تسربت (وهذا يحدث كثيراً عبر الـ GitHub أو الـ Logs)، فسيكون لديك ثغرة مفتوحة لا يمكن إغلاقها بسهولة.

الحل هو استخدام بروتوكولات مصادقة حديثة مثل OAuth 2.0 مع JWT (JSON Web Tokens). لكن حتى هنا، هناك فخاخ يجب تجنبها. مثلاً، الكثيرون يستخدمون الـ JWT بدون توقيع قوي (Strong Signature)، أو يخزنون الـ Secret Key في ملفات التكوين دون تشفير. في عام 2022، تعرضت شركة Optus الأسترالية لهجوم بسبب استخدامهم لـ JWT بدون توقيع قوي، مما سمح للمهاجمين بتعديل الـ Tokens وسرقة بيانات ملايين المستخدمين. الدرس هنا هو أن المصادقة ليست مجرد إضافة مكتبة، بل هي فهم عميق لكيفية عمل الـ Tokens خلف الكواليس.

// مثال على JWT غير آمن (لا تفعل هذا أبداً)
const jwt = require('jsonwebtoken');
const secret = 'my-secret-key'; // ❌ Secret ضعيف ومخزن في الكود

// توليد Token
const token = jwt.sign({ userId: 123 }, secret, { expiresIn: '1h' });

// التحقق من Token
jwt.verify(token, secret, (err, decoded) => {
 if (err) {
 console.log('Invalid token');
 } else {
 console.log('Authenticated!', decoded);
 }
});

// المشكلة: إذا تم تسريب الكود، سيتم تسريب الـ Secret أيضاً
// الحل: استخدم متغيرات بيئة مشفرة وتوقيع قوي مثل HS512 أو RS512

JWT: متى وكيف تستخدمه بشكل صحيح؟

الـ JWT هو معيار قوي للمصادقة، لكنه ليس حلاً سحرياً. يجب أن تفهم متى تستخدمه وكيف. مثلاً، الـ JWT مناسب جداً للتطبيقات التي تعتمد على الـ Stateless Authentication، حيث لا تريد تخزين حالة الجلسة على السيرفر. لكن إذا كنت تبني نظاماً يتطلب مستويات عالية من الأمان مثل البنوك أو الأنظمة الطبية، فقد تحتاج إلى إضافة طبقات إضافية مثل الـ Session Tokens مع الـ JWT أو استخدام بروتوكولات مثل OpenID Connect.

أحد الأخطاء الشائعة هو عدم تحديد مدة صلاحية قصيرة للـ Tokens. إذا تركت الـ Token صالحاً لساعات أو أيام، فأنت تزيد من فرصة استخدامه في هجمات الـ Replay Attacks. الحل هو استخدام مدة صلاحية قصيرة (مثل 15 دقيقة) مع الـ Refresh Tokens. الـ Refresh Token يكون صالحاً لفترة أطول (مثل أسبوع)، ويستخدم للحصول على JWT جديد دون الحاجة لإعادة إدخال بيانات الاعتماد. لكن حتى هنا، يجب أن تخزن الـ Refresh Tokens بشكل آمن في قاعدة بيانات مشفرة، وليس في الـ Local Storage أو الـ Cookies بدون حماية.

# مثال على نظام JWT مع Refresh Tokens (Python + FastAPI)
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
from jose import JWTError, jwt
from pydantic import BaseModel
from datetime import datetime, timedelta
import os

# إعدادات الأمان
SECRET_KEY = os.getenv("JWT_SECRET_KEY") # يجب أن يكون قوياً ومخزن في متغيرات البيئة
ALGORITHM = "HS512"
ACCESS_TOKEN_EXPIRE_MINUTES = 15
REFRESH_TOKEN_EXPIRE_DAYS = 7

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

# نموذج بيانات المستخدم
class User(BaseModel):
 username: str
 email: str

# توليد Access Token
async def create_access_token(data: dict, expires_delta: timedelta = None):
 to_encode = data.copy()
 if expires_delta:
 expire = datetime.utcnow() + expires_delta
 else:
 expire = datetime.utcnow() + timedelta(minutes=15)
 to_encode.update({"exp": expire})
 encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
 return encoded_jwt

# توليد Refresh Token
async def create_refresh_token(data: dict):
 expire = datetime.utcnow() + timedelta(days=REFRESH_TOKEN_EXPIRE_DAYS)
 data.update({"exp": expire, "type": "refresh"})
 encoded_jwt = jwt.encode(data, SECRET_KEY, algorithm=ALGORITHM)
 return encoded_jwt

# التحقق من Access Token
async def get_current_user(token: str = Depends(oauth2_scheme)):
 credentials_exception = HTTPException(
 status_code=status.HTTP_401_UNAUTHORIZED,
 detail="Could not validate credentials",
 headers={"WWW-Authenticate": "Bearer"},
 )
 try:
 payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
 if payload.get("type") == "refresh":
 raise credentials_exception
 username: str = payload.get("sub")
 if username is None:
 raise credentials_exception
 except JWTError:
 raise credentials_exception
 return User(username=username, email=payload.get("email"))

الـ Rate Limiting: لماذا تحتاجها وكيف تنفذها دون قتل الأداء؟

الـ Rate Limiting هو خط الدفاع الأول ضد هجمات الـ DDoS و الـ Brute Force. لكن الكثير من المطورين ينفذونه بطريقة خاطئة، إما باستخدام قواعد بسيطة للغاية (مثل السماح بـ 100 طلب في الدقيقة)، أو باستخدام مكتبات غير فعالة تؤدي إلى الـ Blocking I/O وتجميد السيرفر. المشكلة أن الـ Rate Limiting الفعال يتطلب فهم عميق لكيفية عمل الـ Network Stack و الـ Event Loop في لغتك البرمجية.

في عام 2020، تعرضت شركة Cloudflare لهجوم DDoS ضخم استهدف طبقة التطبيقات (Layer 7). الهجوم استخدم أكثر من 700 مليون عنوان IP لإرسال طلبات إلى واجهات برمجة التطبيقات. بفضل نظام الـ Rate Limiting المتقدم الذي يستخدم خوارزميات مثل الـ Sliding Window و الـ Token Bucket، تمكنت Cloudflare من صد الهجوم دون أي تأثير على الأداء. الدرس هنا هو أن الـ Rate Limiting ليس مجرد عد للطلبات، بل هو نظام ذكي يتكيف مع أنماط الهجوم المختلفة.

خوارزميات الـ Rate Limiting: أيهما تختار؟

هناك عدة خوارزميات للـ Rate Limiting، وكل منها له مميزاته وعيوبه. الخوارزمية الأبسط هي الـ Fixed Window، حيث تقسم الوقت إلى نوافذ ثابتة (مثل دقيقة واحدة) وتسمح بعدد معين من الطلبات في كل نافذة. المشكلة أن هذا النهج يسمح بهجمات الـ Burst، حيث يمكن للمهاجم إرسال جميع الطلبات في آخر ثانية من النافذة. الحل هو استخدام الـ Sliding Window، الذي يحسب الطلبات في آخر نافذة زمنية متحركة، مما يقلل من فرصة الهجمات المفاجئة.

خوارزمية أخرى شائعة هي الـ Token Bucket، حيث يتم إضافة رموز (Tokens) إلى دلو (Bucket) بمعدل ثابت، وكل طلب يستهلك رمزاً. إذا فرغ الدلو، يتم رفض الطلبات الجديدة. هذه الخوارزمية جيدة للأنظمة التي تحتاج إلى السماح ببعض الـ Bursts، لكنها قد تكون معقدة في التنفيذ إذا كنت تريد دعم عدة معدلات مختلفة. في رأيي، الـ Sliding Window هو الخيار الأفضل لمعظم الحالات، لأنه يجمع بين البساطة والفعالية.

// مثال على Rate Limiting باستخدام Sliding Window في Go
package main

import (
	"sync"
	"time"
)

type SlidingWindowLimiter struct {
	mu sync.Mutex
	windowSize time.Duration
	timestamps []time.Time
	maxRequests int
}

func NewSlidingWindowLimiter(windowSize time.Duration, maxRequests int) *SlidingWindowLimiter {
	return &SlidingWindowLimiter{
		windowSize: windowSize,
		maxRequests: maxRequests,
	}
}

func (l *SlidingWindowLimiter) Allow() bool {
	l.mu.Lock()
	defer l.mu.Unlock()

	now := time.Now()
	// إزالة الطلبات القديمة التي خرجت من النافذة
	var validTimestamps []time.Time
	for _, ts := range l.timestamps {
		if now.Sub(ts) <= l.windowSize {
			validTimestamps = append(validTimestamps, ts)
		}
	}
	l.timestamps = validTimestamps

	// التحقق من عدد الطلبات
	if len(l.timestamps) >= l.maxRequests {
		return false
	}

	// إضافة الطلب الحالي
	l.timestamps = append(l.timestamps, now)
	return true
}

// استخدام:
// limiter := NewSlidingWindowLimiter(1*time.Minute, 100)
// if limiter.Allow() {
// // السماح بالطلب
// } else {
// // رفض الطلب
// }

التحديات الحقيقية في تنفيذ الـ Rate Limiting

تنفيذ الـ Rate Limiting يبدو بسيطاً في البداية، لكن هناك تحديات حقيقية تظهر في الإنتاج. أول تحدي هو الـ Distributed Rate Limiting. إذا كان لديك عدة مثيلات من السيرفر خلف موازن تحميل (Load Balancer)، فكيف تضمن أن الـ Rate Limiting يعمل بشكل متسق عبر جميع المثيلات؟ الحل هو استخدام قاعدة بيانات مركزية مثل Redis لتخزين حالة الـ Rate Limiting. لكن حتى هنا، هناك مشكلة في الأداء إذا كان لديك ملايين الطلبات في الثانية، لأن كل طلب سيتطلب عملية قراءة وكتابة على Redis، مما يؤدي إلى الـ Network Latency.

التحدي الثاني هو الـ False Positives. قد يحدث أن المستخدم الشرعي يتعرض للحظر بسبب الـ Rate Limiting، خاصة إذا كان يستخدم تطبيقاً يعتمد على الـ Polling بشكل مكثف. الحل هو استخدام آليات مثل الـ Exponential Backoff أو الـ Adaptive Rate Limiting، حيث يتم تعديل الحد الأقصى للطلبات بناءً على سلوك المستخدم. مثلاً، إذا كان المستخدم يرسل طلبات بشكل منتظم ولم يتجاوز الحد الأقصى، يمكن زيادة الحد مؤقتاً. أما إذا كان يرسل طلبات بشكل عشوائي، فيمكن تقليل الحد.

// مثال على Rate Limiting باستخدام Redis في Node.js
const redis = require("redis");
const { RateLimiterRedis } = require("rate-limiter-flexible");

const redisClient = redis.createClient({
 host: "localhost",
 port: 6379,
});

// إعداد Rate Limiter باستخدام Sliding Window
const rateLimiter = new RateLimiterRedis({
 storeClient: redisClient,
 keyPrefix: "rate_limit",
 points: 100, // عدد الطلبات المسموح بها
 duration: 60, // النافذة الزمنية بالثواني
 blockDuration: 60, // مدة الحظر بالثواني
});

// استخدام في Express middleware
app.use(async (req, res, next) => {
 try {
 const clientId = req.ip; // أو استخدم userId إذا كان المستخدم مسجل الدخول
 await rateLimiter.consume(clientId);
 next();
 } catch (err) {
 res.status(429).json({ error: "Too many requests" });
 }
});

// ملاحظة: في الإنتاج، يجب استخدام Redis Cluster لتجنب الـ Single Point of Failure

الـ API Security: ما وراء المصادقة والـ Rate Limiting

المصادقة والـ Rate Limiting هما مجرد بداية. هناك طبقات أخرى من الأمان يجب أن تفكر فيها إذا كنت تريد حماية API الخاص بك حقاً. مثلاً، الـ Input Validation هو خطوة أساسية لمنع هجمات الـ SQL Injection و الـ XSS. الكثير من المطورين يعتمدون على الـ Frameworks للقيام بهذه المهمة، لكنهم ينسون أن بعض الثغرات تظهر فقط في حالات محددة، مثل عند استخدام الـ Nested Objects أو الـ Arrays في الـ JSON Payloads.

طبقة أخرى مهمة هي الـ API Gateway. بدلاً من تعريض الـ API مباشرة للإنترنت، يمكنك استخدام بوابة (Gateway) مثل Kong أو AWS API Gateway لإدارة الـ Routing و الـ Authentication و الـ Rate Limiting و الـ Logging. البوابة توفر أيضاً طبقة إضافية من الحماية ضد هجمات مثل الـ Path Traversal و الـ HTTP Request Smuggling. في شركة سابقة عملت فيها، استخدمنا Kong مع إضافة مخصصة للـ Rate Limiting باستخدام خوارزمية الـ Sliding Window، مما قلل الهجمات بنسبة 90% خلال شهر واحد.

الـ CORS و الـ CSRF: هل أنت متأكد أنك تفهمهما؟

الـ CORS (Cross-Origin Resource Sharing) هو آلية تسمح للمواقع الأخرى بالوصول إلى مواردك عبر الـ API. المشكلة أن الكثير من المطورين يضبطون الـ CORS بشكل متساهل جداً، مما يسمح لأي موقع بالوصول إلى الـ API. مثلاً، استخدام `Access-Control-Allow-Origin: *` هو خطأ شائع، لأنه يسمح لأي موقع بإرسال طلبات إلى الـ API. الحل هو تحديد النطاقات المسموح بها بشكل دقيق، واستخدام آليات مثل الـ Preflight Requests للتحقق من الطلبات قبل السماح بها.

أما الـ CSRF (Cross-Site Request Forgery)، فهو هجوم يسمح للمهاجم بتنفيذ إجراءات نيابة عن المستخدم دون علمه. مثلاً، إذا كان لديك نقطة نهاية (Endpoint) لتغيير كلمة المرور ولا تتطلب تأكيداً إضافياً، يمكن للمهاجم إنشاء رابط خبيث يرسل طلب POST إلى هذه النقطة. الحل هو استخدام الـ CSRF Tokens، وهي رموز فريدة تُضاف إلى كل طلب وتتغير مع كل جلسة. لكن حتى هنا، يجب أن تتأكد من أن الـ Tokens تُخزن بشكل آمن ولا يمكن تخمينها بسهولة.

# مثال على حماية ضد CSRF في Flask
from flask import Flask, request, session, jsonify
from secrets import token_hex

app = Flask(__name__)
app.secret_key = "your-secret-key-here" # يجب أن يكون قوياً

@app.before_request
def generate_csrf_token():
 if "csrf_token" not in session:
 session["csrf_token"] = token_hex(16)

@app.route("/change-password", methods=["POST"])
def change_password():
 # التحقق من CSRF Token
 if request.form.get("csrf_token") != session.get("csrf_token"):
 return jsonify({"error": "Invalid CSRF token"}), 403
 
 # تغيير كلمة المرور
 new_password = request.form.get("new_password")
 # ... منطق تغيير كلمة المرور ...
 
 # توليد CSRF Token جديد
 session["csrf_token"] = token_hex(16)
 return jsonify({"success": True})

# في الـ Frontend، يجب إضافة الـ CSRF Token إلى كل طلب POST
# مثال باستخدام 
// fetch("/change-password", {
// method: "POST",
// headers: {
// "Content-Type": "application/x-www-form-urlencoded",
// },
// body: `new_password=123456&csrf_token=${sessionStorage.getItem('csrf_token')}`
// });

الخلاصة: كيف تبني API آمن حقاً؟

الأمان ليس شيئاً تضيفه في النهاية، بل هو جزء من تصميم النظام منذ اليوم الأول. ابدأ بالمصادقة القوية باستخدام OAuth 2.0 و JWT مع مدة صلاحية قصيرة و Refresh Tokens. ثم أضف طبقة الـ Rate Limiting باستخدام خوارزميات متقدمة مثل الـ Sliding Window، وتأكد من أنها تعمل بشكل متسق عبر جميع مثيلات السيرفر باستخدام Redis. لا تنسَ طبقات الأمان الأخرى مثل الـ Input Validation و الـ CORS و الـ CSRF، واستخدم بوابة API لإدارة كل هذه الطبقات بشكل مركزي.

وأخيراً، لا تعتمد على الأدوات وحدها. الأمان هو عقلية، وليس مجرد كود. قم بمراجعة الكود بانتظام، واستخدم أدوات مثل OWASP ZAP و Burp Suite لاختبار الثغرات، وتأكد من أن فريقك يفهم كيف تعمل الهجمات وكيفية الدفاع عنها. إذا فعلت كل هذا، فستكون قد بنيت API ليس فقط آمناً، بل أيضاً مرناً وقابلاً للتوسع دون خوف من الثغرات الكارثية.

الأمان ليس منتجاً، بل هو عملية مستمرة. كل سطر من الكود تكتبه يمكن أن يكون ثغرة أو حماية، حسب كيف تكتبه.

— بروس شناير، خبير أمن المعلومات