اشتباهات امنیتی رایج در وب

در یکی از پرونده‌های امنیتی که سال گذشته روی آن کار کردم، یک سایت خبری با ۲۰۰ هزار بازدید ماهانه، با افشای داده روبرو شده بود. جالب این بود که تمام لایه‌های امنیتی موجود بود: HTTPS، Wordfence، پشتیبان‌گیری خودکار و 2FA برای ادمین. اما وقتی گزارش پاکسازی را بررسی کردم، متوجه شدم که سه اشتباه ساده اما پرهزینه در پیکربندی، منجر به نفوذ شده بود: مجوزهای فایل نادرست (644 به جای 755)، کلید مخفی JWT در مخزن Git، و نبود Rate Limiting روی endpoint لاگین. این تجربه نشان می‌دهد که اشتباهات امنیتی رایج، همیشه هم پیچیده نیستند؛ اغلب ساده اما پرهزینه هستند. در این مقاله، بر اساس تجربه‌های مهندسی و مطالعه OWASP، اشتباهات امنیتی رایج در وب را بررسی می‌کنم.

طبق گزارش Verizon Data Breach Investigations Report 2024، حدود ۷۴ درصد از نقض‌های داده شامل عامل انسانی هستند و ۲۱ درصد مربوط به آسیب‌پذیری‌های شناخته‌شده است. طبق گزارش OWASP، بیش از ۹۰ درصد از اپلیکیشن‌های وب حداقل یک آسیب‌پذیری بحرانی دارند. طبق گزارش HackerOne، ۴۰ درصد از برنامه‌های Bug Bounty، حداقل یک آسیب‌پذیری بحرانی (Critical) گزارش می‌کنند. این آمارها نشان می‌دهد که اشتباهات امنیتی رایج، همچنان یکی از بزرگ‌ترین تهدیدات امنیت وب است. اگر با مفاهیم پایه‌ای امنیت آشنا نیستید، پیشنهاد می‌کنم ابتدا امنیت وب چیست و استانداردهای امنیت وب را مطالعه کنید.

اشتباه اول: احراز هویت معیوب

احراز هویت معیوب (Broken Authentication) یکی از رایج‌ترین اشتباهات امنیتی در وب است که در OWASP Top 10 به عنوان A07 و در OWASP API Security Top 10 به عنوان API2 شناخته می‌شود. طبق آمار، حدود ۴۱ درصد از حملات به API از طریق احراز هویت معیوب انجام می‌شود.

شکل‌های رایج احراز هویت معیوب: اول، ذخیره رمز عبور به صورت متن ساده یا با هش ضعیف مثل MD5 یا SHA1. دوم، نبود محدودسازی تلاش‌های ناموفق (Brute Force Protection). سوم، نبود 2FA (Two-Factor Authentication). چهارم، ذخیره توکن‌های احراز هویت در LocalStorage که در برابر XSS آسیب‌پذیر است. پنجم، نبود ابطال Session در زمان Logout یا تغییر رمز عبور.

نمونه یک اشتباه رایج در ذخیره رمز عبور:

// ناامن: هش با MD5
$hash = md5($password);

// ناامن: هش با SHA1
$hash = sha1($password);

// امن: هش با bcrypt
$hash = password_hash($password, PASSWORD_BCRYPT);

// امن‌تر: هش با Argon2
$hash = password_hash($password, PASSWORD_ARGON2ID);

راه‌حل: اول، ذخیره رمز عبور با Argon2id یا bcrypt. دوم، محدودسازی تلاش‌های ناموفق (۵ تلاش، ۱۵ دقیقه قفل). سوم، استفاده از 2FA برای حساب‌های حساس. چهارم، ذخیره توکن در HttpOnly Cookie به جای LocalStorage. پنجم، ابطال Session در زمان Logout و تغییر رمز عبور. اگر با احراز هویت آشنا نیستید، احراز هویت در REST API و بهترین روش‌های احراز هویت را مطالعه کنید.

اشتباه دوم: مجوزدهی سطح منبع ناقص

مجوزدهی سطح منبع ناقص (Broken Object Level Authorization یا BOLA) یکی از پرخطرترین اشتباهات امنیتی است که در OWASP API Security Top 10 رتبه اول را به خود اختصاص داده. طبق آمار، BOLA مسئول بیش از ۴۰ درصد از حملات به API است.

اشتباه رایج: API کاربر را احراز هویت می‌کند اما بررسی نمی‌کند که آیا این کاربر مجاز به دسترسی به منبع درخواستی هست یا نه. این اشتباه، به مهاجم اجازه می‌دهد با تغییر شناسه منبع، به داده‌های کاربران دیگر دسترسی پیدا کند.

نمونه یک endpoint آسیب‌پذیر:

// آسیب‌پذیر: بدون بررسی مالکیت
GET /api/orders/12345
Authorization: Bearer 

// امن: بررسی مالکیت
$orderId = $_GET["order_id"];
$userId = get_current_user_id();

$order = $db->prepare(
    "SELECT * FROM orders WHERE id = ? AND user_id = ?"
);
$order->execute([$orderId, $userId]);

if ($order->rowCount() === 0) {
    http_response_code(403);
    exit("Access denied");
}

راه‌حل: اول، بررسی دقیق دسترسی در سطح منبع در هر درخواست. دوم، استفاده از UUID به جای IDهای ترتیبی. سوم، پیاده‌سازی مجوزدهی مبتنی بر نقش یا ویژگی. چهارم، تست دوره‌ای BOLA در همه endpointهای حساس. پنجم، استفاده از ORM که به طور خودکار بررسی مالکیت را انجام می‌دهد. اگر با امنیت API آشنا نیستید، امنیت API در وب و امنیت API را مطالعه کنید.

اشتباه سوم: افشای اطلاعات حساس

افشای اطلاعات حساس (Sensitive Data Exposure) یکی از اشتباهات رایج است که در OWASP Top 10 به عنوان A02 شناخته می‌شود. این اشتباه، شامل افشای اطلاعات حساس در پاسخ‌های API، لاگ‌ها، پیام‌های خطا یا کد منبع است.

شکل‌های رایج افشای اطلاعات: اول، بازگرداندن کامل آبجکت دیتابیس در پاسخ API (شامل فیلدهای حساس مثل password_hash). دوم، نمایش Stack Trace یا پیام‌های خطای تفصیلی در محیط تولید. سوم، ذخیره اطلاعات حساس در لاگ‌ها. چهارم، استفاده از اطلاعات حساس در URL (مثل API Key در Query String). پنجم، نبود رمزنگاری داده‌های حساس در حالت Rest.

نمونه یک اشتباه رایج در پاسخ API:

// ناامن: بازگرداندن کامل آبجکت
{
  "id": 1,
  "name": "محمد",
  "email": "mohammad@example.com",
  "password_hash": "$2y$10$abc...",
  "internal_id": "INT-12345",
  "role": "admin"
}

// امن: فقط فیلدهای مجاز
{
  "id": 1,
  "name": "محمد",
  "email": "mohammad@example.com"
}

راه‌حل: اول، Output Filtering با Allowlist. دوم، پیام‌های خطای عمومی در محیط تولید. سوم، حذف اطلاعات حساس از لاگ‌ها. چهارم، استفاده از Header به جای URL برای API Key. پنجم، رمزنگاری داده‌های حساس در حالت Rest (مثل رمزنگاری دیتابیس). ششم، استفاده از ابزارهایی مثل .gitignore برای جلوگیری از Commit فایل‌های حساس.

اشتباه چهارم: پیکربندی نادرست امنیتی

پیکربندی نادرست امنیتی (Security Misconfiguration) یکی از رایج‌ترین اشتباهات است که در OWASP Top 10 به عنوان A05 شناخته می‌شود. طبق آمار، بیش از ۹۰ درصد از اپلیکیشن‌های وب حداقل یک نوع اشتباه پیکربندی دارند.

شکل‌های رایج پیکربندی نادرست: اول، استفاده از پیش‌فرض‌های ناامن (مثل admin/admin). دوم، فعال بودن Directory Listing. سوم، نمایش نسخه دقیق نرم‌افزار در هدرها (Server، X-Powered-By). چهارم، مجوزهای فایل نادرست (644 به جای 755). پنجم، فعال بودن پورت‌های غیرضروری. ششم، نبود هدرهای امنیتی مثل CSP و HSTS.

# ناامن: مجوز فایل برای همه
chmod 777 /var/www/html/config.php

# امن: مجوز فایل محدود
chmod 644 /var/www/html/config.php

# امن: مجوز پوشه محدود
chmod 755 /var/www/html/

# امن: مجوز فایل حساس
chmod 600 /var/www/html/.env

راه‌حل: اول، حذف پیش‌فرض‌ها و استفاده از پیکربندی سفارشی. دوم، غیرفعال کردن Directory Listing. سوم، حذف یا پنهان کردن نسخه نرم‌افزار در هدرها. چهارم، تنظیم مجوزهای فایل به صورت استاندارد (644 فایل، 755 پوشه). پنجم، بستن پورت‌های غیرضروری. ششم، فعال کردن هدرهای امنیتی مثل CSP، HSTS، X-Frame-Options. هفتم، استفاده از ابزار Mozilla Observatory برای تست پیکربندی. اگر با هدرهای امنیتی آشنا نیستید، راهنمای هدرهای امنیتی HTTP را مطالعه کنید.

اشتباه پنجم: مدیریت نادرست Secretها

مدیریت نادرست Secretها یکی از پرخطرترین اشتباهات امنیتی است که در پروژه‌های مختلف زیاد دیده‌ام. Secretها شامل کلیدهای API، رمزهای دیتابیس، کلیدهای JWT، و سایر اطلاعات حساس است. اگر این اطلاعات افشا شوند، مهاجم می‌تواند به راحتی به سیستم نفوذ کند.

شکل‌های رایج مدیریت نادرست Secretها: اول، ذخیره Secretها در مخزن Git (فایل‌های .env که به Git Push شده‌اند). دوم، Hardcode کردن Secretها در کد منبع. سوم، ذخیره Secretها در فایل‌های با مجوز نادرست. چهارم، ارسال Secretها از طریق کانال‌های ناامن. پنجم، استفاده از یک Secret برای همه محیط‌ها (dev، staging، production). ششم، نبود Rotation منظم Secretها.

نمونه یک اشتباه رایج:

# ناامن: در فایل .env که Commit شده
DATABASE_PASSWORD=mysecretpassword
JWT_SECRET=my_jwt_secret_key

# امن: استفاده از Environment Variables در سرور
# و ذخیره در Secret Manager
# - AWS Secrets Manager
# - HashiCorp Vault
# - Azure Key Vault

راه‌حل: اول، هرگز Secretها را در مخزن Git نگه ندارید. دوم، از .gitignore برای فایل‌های حساس استفاده کنید. سوم، از Environment Variables یا Secret Manager استفاده کنید. چهارم، Secretهای مختلف برای هر محیط داشته باشید. پنجم، Rotation منظم Secretها. ششم، پایش مخزن Git برای Secretهای افشا‌شده با ابزارهایی مثل GitGuardian یا Trufflehog. هفتم، در صورت افشای Secret، فوراً آن را Rotate کنید. اگر با Git آشنا نیستید، گیت در وردپرس و آموزش Git از صفر را مطالعه کنید.

مدیریت Secretها، نه یک کار فنی، بلکه یک فرهنگ است. تیم‌هایی که Secretها را جدی می‌گیرند، در بلندمدت امن‌تر هستند.

اشتباه ششم: نبود Rate Limiting

نبود Rate Limiting یکی از رایج‌ترین اشتباهات امنیتی است که در OWASP API Security Top 10 به عنوان API4 شناخته می‌شود. بدون Rate Limiting، یک مهاجم می‌تواند با ارسال درخواست‌های زیاد، سرویس را از کار بیندازد یا منابع را مصرف کند.

شکل‌های رایج این اشتباه: اول، نبود محدودیت روی endpoint لاگین (منجر به Brute Force). دوم، نبود محدودیت روی endpointهای پرهزینه (مثل تولید گزارش). سوم، نبود محدودیت روی endpointهای عمومی (منجر به DDoS). چهارم، نبود محدودیت بر اساس هویت کلاینت (فقط بر اساس IP که با Proxy قابل دور زدن است).

# نمونە پیکربندی در Nginx
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m;

server {
    location /login {
        limit_req zone=login burst=3 nodelay;
    }
    location /api/ {
        limit_req zone=api burst=20 nodelay;
    }
}

راه‌حل: اول، پیاده‌سازی Rate Limiting بر اساس هویت کلاینت (API Key یا توکن). دوم، محدودیت‌های متفاوت برای endpointهای مختلف. سوم، استفاده از هدرهای استاندارد X-RateLimit-* و Retry-After. چهارم، پیاده‌سازی در لایه Gateway، نه در هر سرویس. پنجم، پایش مداوم و تنظیم مجدد محدودیت‌ها. اگر با امنیت API آشنا نیستید، امنیت API در وب و احراز هویت در REST API را مطالعه کنید.

اشتباه هفتم: رمزنگاری ضعیف

رمزنگاری ضعیف یکی از اشتباهات امنیتی است که در OWASP Top 10 به عنوان A02 (Cryptographic Failures) شناخته می‌شود. این اشتباه، شامل استفاده از الگوریتم‌های ضعیف، پیکربندی نادرست، یا مدیریت نادرست کلیدها است.

شکل‌های رایج رمزنگاری ضعیف: اول، استفاده از MD5 یا SHA1 برای هش رمز عبور. دوم، استفاده از ECB Mode در رمزنگاری متقارن. سوم، استفاده از کلیدهای کوتاه یا قابل حدس. چهارم، استفاده از الگوریتم‌های ضعیف مثل DES یا RC4. پنجم، نبود Salt در هش رمز عبور. ششم، استفاده از Random ناامن (مثل rand() در PHP به جای random_bytes()).

// ناامن: هش با MD5 بدون Salt
$hash = md5($password);

// ناامن: Random ناامن
$token = rand(100000, 999999);

// امن: هش با Argon2id
$hash = password_hash($password, PASSWORD_ARGON2ID);

// امن: Random امن
$token = bin2hex(random_bytes(32));

راه‌حل: اول، استفاده از Argon2id یا bcrypt برای هش رمز عبور. دوم، استفاده از AES-GCM یا ChaCha20-Poly1305 برای رمزنگاری متقارن. سوم، استفاده از کلیدهای طولانی و تصادفی (حداقل ۲۵۶ بیت). چهارم، Salt منحصربه‌فرد برای هر کاربر. پنجم، استفاده از random_bytes() یا RandomRandomizer در PHP. ششم، مدیریت درست کلیدها (Rotation، Backup، Access Control). اگر به امنیت علاقه‌مندید، SSL و HTTPS در امنیت و راهنمای هدرهای امنیتی HTTP را مطالعه کنید.

اشتباه هشتم: نبود پایش و لاگ

نبود پایش و لاگ (Insufficient Logging and Monitoring) یکی از اشتباهات رایج است که در OWASP Top 10 به عنوان A09 شناخته می‌شود. بدون پایش، حتی موفق‌ترین حملات می‌توانند هفته‌ها یا ماه‌ها بی‌سر و صدا بمانند.

شکل‌های رایج این اشتباه: اول، نبود لاگ رویدادهای امنیتی مهم (تلاش‌های ناموفق ورود، تغییرات در دسترسی‌ها). دوم، ذخیره لاگ‌ها در محل قابل دسترس مهاجم. سوم، نبود هشدار Real-time برای رویدادهای بحرانی. چهارم، نبود پایش ترافیک مشکوک. پنجم، نبود SIEM (Security Information and Event Management). ششم، عدم بازبینی دوره‌ای لاگ‌ها.

# نمونە لاگ امنیتی در PHP
error_log(sprintf(
    "[SECURITY] Failed login attempt for user=%s ip=%s time=%s",
    $username,
    $_SERVER["REMOTE_ADDR"],
    date("c")
));

راه‌حل: اول، لاگ همه رویدادهای امنیتی مهم. دوم، ذخیره لاگ‌ها در محل مرکزی که در دسترس مهاجم نباشد. سوم، هشدار Real-time برای رویدادهای بحرانی. چهارم، پایش ترافیک مشکوک با ابزارهایی مثل WAF. پنجم، استفاده از SIEM (مثل ELK Stack، Splunk، یا Datadog Security). ششم، بازبینی دوره‌ای لاگ‌ها. هفتم، ذخیره لاگ‌ها برای مدت کافی (معمولاً ۹۰ روز یا بیشتر). اگر با ابزارهای پایش سرور آشنا نیستید، مقایسه ابزارهای مانیتورینگ سرور را مطالعه کنید.

اشتباه نهم: مدیریت نادرست وابستگی‌ها

مدیریت نادرست وابستگی‌ها (Vulnerable and Outdated Components) یکی از اشتباهات امنیتی است که در OWASP Top 10 به عنوان A06 شناخته می‌شود. طبق گزارش Sonatype، بیش از ۲۴۵,۰۰۰ بسته مخرب در مخازن عمومی کشف شده است و بیش از ۷۰ درصد از اپلیکیشن‌ها از وابستگی‌های آسیب‌پذیر استفاده می‌کنند.

شکل‌های رایج این اشتباه: اول، استفاده از نسخه‌های قدیمی کتابخانه‌ها و افزونه‌ها. دوم، نبود پایش مداوم برای CVEهای جدید. سوم، نصب وابستگی‌ها از منابع ناشناس (نه از مخازن رسمی). چهارم، نبود Lock File برای وابستگی‌ها. پنجم، نبود SRI (Subresource Integrity) برای فایل‌های CDN. ششم، استفاده از افزونه‌های وردپرسی بدون به‌روزرسانی.

نمونه یک Lock File:

# package-lock.json (npm)
{
  "dependencies": {
    "lodash": {
      "version": "4.17.21",
      "integrity": "sha512-..."
    }
  }
}

راه‌حل: اول، به‌روزرسانی منظم وابستگی‌ها. دوم، پایش مداوم برای CVEهای جدید با ابزارهایی مثل Snyk، Dependabot یا npm audit. سوم، استفاده از Lock File برای تعیین دقیق نسخه‌ها. چهارم، استفاده از SRI برای فایل‌های خارجی. پنجم، نصب وابستگی‌ها فقط از مخازن رسمی. ششم، حذف وابستگی‌های بی‌استفاده. هفتم، در وردپرس، به‌روزرسانی منظم افزونه‌ها و قالب‌ها. اگر با امنیت وردپرس کار می‌کنید، راهنمای امنیت وردپرس و بهترین افزونه‌های امنیتی وردپرس را مطالعه کنید.

اشتباه دهم: نبود آموزش تیم

نبود آموزش تیم یکی از اشتباهات امنیتی است که کمتر مورد توجه قرار می‌گیرد اما در واقع یکی از پرهزینه‌ترین است. طبق گزارش Verizon، ۷۴ درصد از نقض‌های داده شامل عامل انسانی هستند. یعنی حتی بهترین کنترل‌های فنی، اگر تیم آموزش ندیده باشد، بی‌اثر می‌شوند.

شکل‌های رایج این اشتباه: اول، نبود آموزش امنیتی برای توسعه‌دهندگان. دوم، نبود آموزش برای تیم تولید محتوا (مثلاً درباره فیشینگ). سوم، نبود آموزش برای تیم ادمین (مثلاً درباره مدیریت Secretها). چهارم، نبود فرهنگ بازپرسی امنیتی (Security Review). پنجم، نبود مستندسازی امنیتی. ششم، نبود تمرین دوره‌ای برای پاسخ به حادثه.

راه‌حل: اول، آموزش منظم امنیتی برای همه اعضای تیم. دوم، تمرین دوره‌ای برای پاسخ به حادثه. سوم، مستندسازی استانداردهای امنیتی. چهارم، بازپرسی امنیتی در Code Review. پنجم، استفاده از ابزارهای خودکار برای شناسایی آسیب‌پذیری (مثل SAST، DAST، SCA). ششم، ترویج فرهنگ امنیت در همه سطوح سازمان. هفتم، آموزش تیم تولید محتوا درباره فیشینگ و مهندسی اجتماعی. اگر با امنیت API آشنا نیستید، امنیت API در وب و امنیت API را مطالعه کنید.

امنیت، نه یک محصول است، نه یک پروژه. یک فرهنگ است. فرهنگ از آموزش شروع می‌شود و با تمرین شکل می‌گیرد.

پرسش‌های پرتکرار درباره اشتباهات امنیتی

کدام اشتباه امنیتی خطرناک‌تر است؟ بستگی به سناریو دارد، اما سه اشتباه با اثر بالا: احراز هویت معیوب (منجر به دسترسی غیرمجاز)، افشای اطلاعات حساس (منجر به نقض داده)، و مدیریت نادرست Secretها (منجر به نفوذ کامل). این سه اشتباه، معمولاً در ترکیب با هم، منجر به فاجعه می‌شوند.

آیا استفاده از فریمورک امن جلوی همه اشتباهات را می‌گیرد؟ فریمورک‌های مدرن مثل Laravel، Django و Rails، بسیاری از کنترل‌های امنیتی را به طور پیش‌فرض فراهم می‌کنند. اما این محافظت مطلق نیست. سه اشتباه رایج در فریمورک‌ها: استفاده از کوئری‌های خام، نبود Output Filtering، و پیکربندی نادرست.

آیا برای سایت‌های کوچک هم این اشتباهات مهم است؟ بله. سایت‌های کوچک هم می‌توانند هدف حملات خودکار باشند. اکثر حملات، توسط ربات‌ها انجام می‌شود که به دنبال آسیب‌پذیری‌های شناخته‌شده می‌گردند. یک سایت کوچک با احراز هویت معیوب، می‌تواند به راحتی هک شود.

چگونه بفهمم سایتم چه اشتباهاتی دارد؟ از ابزارهای خودکار استفاده کنید: Mozilla Observatory برای پیکربندی، Qualys SSL Labs برای SSL، OWASP ZAP برای آسیب‌پذیری‌های رایج، و Snyk برای وابستگی‌ها. علاوه بر این، از برنامه Bug Bounty برای شناسایی آسیب‌پذیری‌های پیچیده‌تر استفاده کنید.

آیا باید نگران اشتباهات امنیتی در وردپرس باشم؟ بله. وردپرس به دلیل محبوبیت، هدف اصلی حملات است. سه اشتباه رایج در وردپرس: استفاده از افزونه‌های قدیمی، پیکربندی نادرست wp-config، و نبود 2FA برای ادمین. اگر با امنیت وردپرس کار می‌کنید، راهنمای امنیت وردپرس و اشتباهات رایج امنیت وردپرس را مطالعه کنید.

چگونه تیم را درباره امنیت آموزش دهم؟ سه رویکرد اصلی: اول، آموزش مستمر (Workshop، دوره‌های آنلاین، مطالعه مقالات). دوم، تمرین عملی (Bug Bounty داخلی، CTF). سوم، ترویج فرهنگ امنیت در همه سطوح (Security Review در Code Review، هشدار درباره فیشینگ، بازپرسی دوره‌ای Secretها).

آیا ابزارهای امنیتی می‌توانند جایگزین آموزش تیم شوند؟ خیر. ابزارها بخش بزرگی از مشکلات را شناسایی می‌کنند، اما اشتباهات منطقی (مثل BOLA، نادرست استفاده از یک کتابخانه) را معمولاً تشخیص نمی‌دهند. آموزش تیم، مکمل ابزارها است، نه جایگزین آنها.

آنچه باید با خود ببرید

اشتباهات امنیتی رایج در وب، ده مورد اصلی هستند که در این مقاله بررسی کردیم: احراز هویت معیوب، مجوزدهی سطح منبع ناقص، افشای اطلاعات حساس، پیکربندی نادرست، مدیریت نادرست Secretها، نبود Rate Limiting، رمزنگاری ضعیف، نبود پایش و لاگ، مدیریت نادرست وابستگی‌ها، و نبود آموزش تیم. این ده اشتباه، مسئول بخش بزرگی از نقض‌های داده در سال‌های اخیر هستند.

هفت اصل کلیدی برای اجتناب از این اشتباهات:

1. احراز هویت قوی با Argon2id، 2FA و محدودسازی تلاش‌های ناموفق.
2. مجوزدهی سطح منبع در هر درخواست، بدون استثنا.
3. Output Filtering با Allowlist و پیام‌های خطای عمومی.
4. مدیریت Secretها با Environment Variables یا Secret Manager، هرگز در Git.
5. Rate Limiting بر اساس هویت کلاینت در همه endpointهای حساس.
6. رمزنگاری مدرن با Argon2id، AES-GCM و Random امن.
7. پایش مداوم، لاگ مرکزی و آموزش تیم، پایه فرهنگ امنیت.

قدم عملی امروز: یک لیست از ده اشتباه امنیتی بالا بسازید و برای هرکدام، وضعیت پروژه خود را علامت‌گذاری کنید: انجام شده، انجام نشده، یا نیاز به بررسی. از مهم‌ترین موارد شروع کنید: احراز هویت، مجوزدهی سطح منبع، و مدیریت Secretها. این سه، ۶۰ درصد از ریسک امنیتی را پوشش می‌دهند. اگر می‌خواهید عمیق‌تر شوید، امنیت وب چیست و استانداردهای امنیت وب را مطالعه کنید.

اگر تجربه‌ای در مواجهه با یکی از این اشتباهات امنیتی داشتید — به‌خصوص اگر با یک حادثه واقعی روبرو شده‌اید یا یک اشتباه رایج را در پروژه خود کشف کرده‌اید — در دیدگاه‌ها بنویسید. این تجربه‌ها برای خواننده‌های بعدی از هر مقاله تئوریک ارزشمندتر است. 🔒