آیا یک نرم‌افزار فقط زمانی باکیفیت است که درست کار کند؟ پاسخ قطعاً نه است. یک نرم‌افزار خوب علاوه بر عملکرد صحیح، باید در برابر دسترسی‌های غیرمجاز، سوءاستفاده از قابلیت‌ها و تهدیدهای امنیتی نیز مقاوم باشد.

اینجاست که Security Testing یا تست امنیت اهمیت پیدا می‌کند. Security Testing به ما کمک می‌کند بررسی کنیم آیا یک نرم‌افزار اطلاعات، کاربران و قابلیت‌های خود را به شکل امن مدیریت می‌کند یا خیر.

اما یک سؤال مهم برای Software Testerها وجود دارد:

آیا برای ورود به حوزه تست امنیت باید یک متخصص امنیت یا Penetration Tester باشیم؟

خیر.

یک Software Tester می‌تواند با تکیه بر مهارت‌های فعلی خود و با یادگیری تدریجی مفاهیم امنیتی، Security Testing را وارد فرآیند روزمره Testing کند.

در این مقاله قرار است از پایه شروع کنیم و ببینیم یک Tester برای ورود به دنیای Security Testing چه چیزهایی باید بداند، چه ابزارهایی می‌تواند استفاده کند و چگونه می‌تواند یک Feature را با ذهنیت امنیتی بررسی کند. 🔐

Table of Contents

فهرست مطالب

تست امنیت یا Security Testing چیست؟ 🔐

Security Testing مجموعه‌ای از فعالیت‌های تست است که با هدف شناسایی ضعف‌ها و مشکلات امنیتی در یک نرم‌افزار انجام می‌شود.

در تست Functional معمولاً سؤال اصلی این است:

«آیا سیستم همان کاری را که باید انجام دهد، درست انجام می‌دهد؟»

اما در Security Testing سؤال تغییر می‌کند:

«آیا سیستم فقط به افراد مجاز اجازه انجام کارهای مجاز را می‌دهد؟»

برای مثال فرض کنید یک کاربر می‌تواند سفارش خودش را مشاهده کند. از دید Functional Testing، کافی است بررسی کنیم سفارش به‌درستی نمایش داده می‌شود.

اما یک Security Tester سؤال‌های بیشتری می‌پرسد:

  • آیا کاربر می‌تواند سفارش کاربر دیگری را مشاهده کند؟
  • اگر شناسه سفارش را تغییر دهیم چه اتفاقی می‌افتد؟
  • آیا بدون Login می‌توان به سفارش دسترسی داشت؟
  • آیا API همان محدودیت‌های UI را اعمال می‌کند؟
  • آیا بعد از Logout همچنان امکان مشاهده سفارش وجود دارد؟

همین تغییر در نوع سؤال پرسیدن، یکی از مهم‌ترین تفاوت‌های بین یک Tester معمولی و یک Security-Aware Tester است.

چرا Security Testing برای Software Tester مهم است؟ 🎯

امنیت فقط وظیفه تیم Security نیست. در یک تیم نرم‌افزاری، هر فردی که با محصول، Requirement، کد، تست یا Deployment درگیر است می‌تواند در بهبود امنیت محصول نقش داشته باشد.

Software Tester به دلیل جایگاهی که در فرآیند توسعه دارد، می‌تواند بسیاری از مشکلات امنیتی را در همان مراحل ابتدایی شناسایی کند.

برای مثال، Tester هنگام بررسی یک Feature می‌تواند علاوه بر Happy Path، سناریوهای زیر را نیز بررسی کند:

  • کاربر غیرمجاز چه کاری می‌تواند انجام دهد؟
  • آیا Permissionها درست اعمال شده‌اند؟
  • آیا اطلاعات حساس در Response نمایش داده می‌شوند؟
  • آیا API بدون Authentication قابل استفاده است؟
  • آیا می‌توان محدودیت‌های Business را دور زد؟

بنابراین Security Testing را می‌توان به‌عنوان یک مهارت مکمل برای Software Testing در نظر گرفت؛ مهارتی که باعث می‌شود Tester نرم‌افزار را فقط از نظر درست کار کردن، بلکه از نظر امن کار کردن نیز بررسی کند.

تفاوت Software Testing و Security Testing

Functional Testing و Security Testing رقیب یکدیگر نیستند. در واقع Security Testing را می‌توان یکی از زاویه‌های مهم بررسی کیفیت نرم‌افزار دانست.

Functional TestingSecurity Testing
آیا Feature درست کار می‌کند؟آیا Feature به شکل امن کار می‌کند؟
آیا User می‌تواند Login کند؟آیا Login قابل دور زدن است؟
آیا Order نمایش داده می‌شود؟آیا فقط صاحب Order می‌تواند آن را ببیند؟
آیا API پاسخ صحیح می‌دهد؟آیا API فقط به User مجاز پاسخ می‌دهد؟

در واقع یک Tester حرفه‌ای می‌تواند هر دو نوع نگاه را هم‌زمان داشته باشد.

Security Mindset چیست؟ 🧠

یکی از مهم‌ترین مفاهیمی که یک Tester باید در مسیر Security Testing یاد بگیرد، Security Mindset است.

Security Mindset یعنی هنگام تست فقط به این فکر نکنیم که:

«کاربر معمولی چگونه از این Feature استفاده می‌کند؟»

بلکه بپرسیم:

«اگر کسی بخواهد از این Feature سوءاستفاده کند، چه اتفاقی ممکن است بیفتد؟»

مثلاً اگر Application یک Endpoint به شکل زیر داشته باشد:

GET /api/orders/123

یک Tester با ذهنیت Functional ممکن است فقط بررسی کند که Order شماره 123 به‌درستی نمایش داده می‌شود.

اما Security Tester سؤال‌های بیشتری مطرح می‌کند:

  • چه کسی می‌تواند این Endpoint را فراخوانی کند؟
  • اگر عدد 123 را تغییر دهیم چه می‌شود؟
  • آیا User دیگری می‌تواند Order را مشاهده کند؟
  • اگر Token حذف شود چه اتفاقی می‌افتد؟
  • اگر Token متعلق به User دیگری باشد چه؟

این نوع نگاه، پایه اصلی Security Testing است.

اهداف اصلی Security Testing چیست؟ 🎯

هدف Security Testing فقط پیدا کردن Vulnerability نیست. یک فرآیند مناسب Security Testing باید به ما کمک کند بفهمیم آیا Application در برابر دسترسی غیرمجاز، سوءاستفاده و افشای اطلاعات مقاوم است یا خیر.

مهم‌ترین اهداف Security Testing عبارت‌اند از:

  • شناسایی Vulnerabilityهای امنیتی
  • بررسی Authentication و Authorization
  • جلوگیری از دسترسی غیرمجاز
  • بررسی حفاظت از اطلاعات حساس
  • بررسی Session Management
  • بررسی Input Validation
  • بررسی Security Configuration
  • شناسایی مشکلات Business Logic

سه مفهوم مهم در امنیت اطلاعات: CIA Triad 🔐

یکی از مفاهیم پایه‌ای در Security، مدل CIA Triad است. این مدل سه هدف اصلی امنیت اطلاعات را توضیح می‌دهد:

Confidentiality؛ محرمانگی

اطلاعات فقط باید در اختیار افرادی قرار بگیرد که مجوز دسترسی به آن را دارند.

مثلاً یک User نباید بتواند اطلاعات شخصی User دیگری را مشاهده کند.

Integrity؛ یکپارچگی

اطلاعات نباید توسط افراد غیرمجاز تغییر داده شوند.

برای مثال، یک User معمولی نباید بتواند Role خودش را از user به admin تغییر دهد.

Availability؛ دسترس‌پذیری

سیستم و اطلاعات باید در زمان موردنیاز برای کاربران مجاز در دسترس باشند.

در Security Testing ممکن است بخشی از بررسی‌ها به رفتار Application در برابر درخواست‌های غیرعادی یا مصرف بیش از حد منابع مربوط شود.

Authentication چیست؟ 🔑

Authentication یعنی سیستم هویت کاربر را بررسی کند.

به زبان ساده:

Authentication یعنی «تو چه کسی هستی؟»

مثلاً زمانی که User با Username و Password وارد سیستم می‌شود، Application باید بررسی کند که Credentialهای ارائه‌شده معتبر هستند یا خیر.

اما موفق بودن Authentication به این معنی نیست که User اجازه انجام هر کاری را دارد.

Authorization چیست؟ 👤

Authorization مشخص می‌کند یک User احراز هویت‌شده چه کارهایی اجازه دارد انجام دهد.

Authorization یعنی «اجازه انجام چه کاری را داری؟»

فرض کنید یک Application سه Role دارد:

Guest
User
Admin

ممکن است هر سه Role بتوانند Application را مشاهده کنند، اما فقط User و Admin اجازه ایجاد Order داشته باشند و فقط Admin بتواند Userها را مدیریت کند.

یکی از مهم‌ترین وظایف Tester این است که بررسی کند این Permissionها واقعاً در Backend نیز enforce شده‌اند.

تفاوت Authentication و Authorization

مفهومسؤال اصلیمثال
Authenticationچه کسی هستی؟ورود با Username و Password
Authorizationچه کاری اجازه داری؟آیا User اجازه حذف Order را دارد؟

این تفاوت ساده یکی از پایه‌ای‌ترین مفاهیمی است که یک Tester هنگام ورود به Security Testing باید به‌خوبی درک کند.

Session Management چیست؟ 🍪

بعد از اینکه User احراز هویت شد، Application باید بتواند وضعیت Login او را مدیریت کند. این وظیفه معمولاً با استفاده از Session یا Token انجام می‌شود.

Tester باید رفتار Session را در شرایط مختلف بررسی کند.

  • بعد از Login چه چیزی ایجاد می‌شود؟
  • Session چه مدت اعتبار دارد؟
  • بعد از Logout چه اتفاقی می‌افتد؟
  • آیا Session قبلی invalidate می‌شود؟
  • بعد از تغییر Password چه اتفاقی برای Sessionهای قبلی می‌افتد؟
  • آیا Cookieهای حساس به شکل مناسبی مدیریت می‌شوند؟

Input Validation چیست؟ 🧪

تقریباً هر Application داده‌ای از کاربر دریافت می‌کند؛ از Username و Search Query گرفته تا اطلاعات فرم، فایل و API Request.

یکی از وظایف مهم Application این است که Inputهای دریافتی را به شکل مناسب بررسی و پردازش کند.

Tester می‌تواند بررسی کند که Application با Inputهای غیرمنتظره چگونه رفتار می‌کند.

  • مقدار خالی
  • مقدار بسیار طولانی
  • نوع داده اشتباه
  • کاراکترهای خاص
  • مقادیر خارج از محدوده
  • داده‌های غیرمنتظره

در مراحل پیشرفته‌تر، همین موضوع به بررسی Vulnerabilityهایی مانند SQL Injection و XSS نیز مرتبط می‌شود.

Broken Access Control چیست؟ 🚨

Broken Access Control زمانی رخ می‌دهد که Application نتواند محدودیت‌های دسترسی را به‌درستی اعمال کند.

یک مثال ساده:

User A
    ↓
GET /api/orders/123

Order 123 متعلق به User B است.

اگر User A بتواند با تغییر شناسه، اطلاعات Order متعلق به User B را مشاهده کند، با یک مشکل جدی در Access Control مواجه هستیم.

این نوع مشکل ممکن است با اصطلاحاتی مانند IDOR یا BOLA نیز شناخته شود؛ البته تشخیص دقیق دسته‌بندی به Context و رفتار واقعی Application بستگی دارد.

Business Logic در Security Testing

همه مشکلات امنیتی از یک نقص فنی ساده ایجاد نمی‌شوند. گاهی Application از نظر Authentication و Authorization درست کار می‌کند، اما منطق کسب‌وکار آن قابل سوءاستفاده است.

مثلاً فرض کنید یک فروشگاه می‌گوید هر User فقط یک بار می‌تواند از یک Coupon استفاده کند.

Tester باید بررسی کند که آیا می‌توان با تغییر ترتیب درخواست‌ها، تغییر مقدارها یا تکرار یک Workflow این محدودیت را دور زد یا خیر.

این همان جایی است که Business Logic Testing و Security Testing به یکدیگر نزدیک می‌شوند.

OWASP Top 10 چیست؟ 🌐

OWASP Top 10 یکی از شناخته‌شده‌ترین منابع برای آشنایی با ریسک‌های رایج امنیتی در Web Applicationهاست.

برای یک Software Tester، هدف از مطالعه OWASP Top 10 نباید صرفاً حفظ کردن نام Vulnerabilityها باشد.

بهتر است برای هر موضوع بتوانیم به چهار سؤال پاسخ دهیم:

  1. این مشکل چیست؟
  2. چرا ایجاد می‌شود؟
  3. در چه Featureهایی ممکن است دیده شود؟
  4. چگونه می‌توان آن را تست کرد؟

این روش باعث می‌شود OWASP از یک لیست تئوری به یک ابزار ذهنی برای طراحی Test Scenario تبدیل شود.

Security Testing فقط پیدا کردن Vulnerability نیست

یک اشتباه رایج این است که تصور کنیم Security Testing یعنی اجرای یک Scanner و پیدا کردن چند Vulnerability.

در واقع فرآیند Security Testing می‌تواند شامل این مراحل باشد:

  1. شناخت Application
  2. شناخت Requirement و Business Rule
  3. شناسایی Roleها و Permissionها
  4. طراحی Security Scenario
  5. اجرای تست
  6. تحلیل رفتار Application
  7. اعتبارسنجی Finding
  8. بررسی Impact
  9. ثبت Bug Report
  10. Regression Testing بعد از Fix

بنابراین ابزار فقط یکی از اجزای Security Testing است و جایگزین تفکر و تحلیل Tester نمی‌شود.

انواع Security Testing کدام‌اند؟ 🛡️

Security Testing یک عنوان کلی است و روش‌ها و رویکردهای مختلفی را شامل می‌شود. شناخت این دسته‌بندی‌ها به Software Tester کمک می‌کند جایگاه خودش را در فرآیند امنیت نرم‌افزار بهتر درک کند.

1. Vulnerability Assessment

در Vulnerability Assessment هدف اصلی شناسایی و ارزیابی ضعف‌های امنیتی شناخته‌شده در یک سیستم است.

در این رویکرد ممکن است از ابزارهای Automated Scanning برای پیدا کردن مشکلات احتمالی استفاده شود.

اما یک نکته مهم وجود دارد:

هر Finding یک Vulnerability قطعی نیست.

برخی نتایج Scanner ممکن است False Positive باشند و نیاز به بررسی و Validation دستی داشته باشند.

2. Penetration Testing

Penetration Testing یا Pentest رویکردی عمیق‌تر برای شناسایی و بررسی قابلیت سوءاستفاده از ضعف‌های امنیتی است.

در Pentest، متخصص امنیت تلاش می‌کند با استفاده از روش‌های کنترل‌شده مشخص کند آیا یک ضعف واقعاً قابل Exploit است و چه اثری می‌تواند داشته باشد.

Software Tester لازم نیست حتماً Penetration Tester باشد، اما شناخت مفاهیم Pentest می‌تواند در طراحی Security Test Scenarioها بسیار مفید باشد.

3. Security Testing در سطح Application

در این رویکرد Application را از منظرهای مختلف امنیتی بررسی می‌کنیم.

  • Authentication
  • Authorization
  • Session Management
  • Input Validation
  • File Upload
  • Access Control
  • Error Handling
  • Information Disclosure
  • Business Logic

این بخش بیشترین ارتباط را با کار روزمره یک Web یا API Tester دارد.

4. API Security Testing

امروزه بسیاری از Applicationها بخش بزرگی از منطق خود را از طریق API ارائه می‌کنند. بنابراین Security Testing نباید فقط به UI محدود شود.

در API Security Testing می‌توان مواردی مانند Authentication، Authorization، Input Validation و Data Exposure را بررسی کرد.

برای مثال:

GET /api/users/123

Tester باید بررسی کند که آیا User فعلی مجاز به دریافت اطلاعات User شماره 123 است یا خیر.

5. Mobile Security Testing

در Mobile Security Testing، Applicationهای موبایل از نظر امنیتی بررسی می‌شوند.

موضوعاتی مانند ذخیره‌سازی اطلاعات حساس، ارتباط با API، Authentication، Session و رفتار Application در Device مورد توجه قرار می‌گیرند.

اگرچه این حوزه تخصص‌های بیشتری نیاز دارد، اما Testerهای موبایل نیز می‌توانند به‌تدریج مفاهیم Security Testing را وارد فرآیند تست خود کنند.

6. Security Configuration Testing

گاهی مشکل امنیتی در منطق Application نیست، بلکه از Configuration نادرست ایجاد می‌شود.

برای مثال:

  • Security Headerهای نامناسب
  • فعال بودن Featureهای غیرضروری
  • تنظیمات ناامن
  • نمایش اطلاعات غیرضروری در Error Response

Tester می‌تواند در محدوده مسئولیت خود این موارد را شناسایی و در صورت نیاز به تیم مربوطه گزارش کند.

SAST چیست؟ 🔍

SAST مخفف Static Application Security Testing است.

در SAST، Source Code یا Artifactهای مربوط به Application بدون اجرای واقعی Application از نظر الگوهای امنیتی بررسی می‌شوند.

هدف این است که برخی مشکلات امنیتی از مراحل نسبتاً ابتدایی Development شناسایی شوند.

برای یک Tester، مهم است بداند SAST چه کاری انجام می‌دهد، حتی اگر خودش مسئول اجرای ابزار SAST نباشد.

DAST چیست؟ 🌐

DAST مخفف Dynamic Application Security Testing است.

در DAST، Application در حال اجرا از بیرون مورد بررسی قرار می‌گیرد.

به همین دلیل DAST ارتباط بیشتری با Web Security Testing دارد و می‌تواند رفتار Application را در زمان اجرا بررسی کند.

SCA چیست؟ 📦

SCA مخفف Software Composition Analysis است.

Applicationهای امروزی از تعداد زیادی Library و Third-Party Dependency استفاده می‌کنند. اگر یکی از این Dependencyها دارای Vulnerability شناخته‌شده باشد، می‌تواند برای Application نیز ریسک ایجاد کند.

SCA به تیم کمک می‌کند Dependencyها و ریسک‌های شناخته‌شده مربوط به آن‌ها را شناسایی کند.

SAST، DAST و SCA چه تفاوتی دارند؟

روشچه چیزی را بررسی می‌کند؟زمان معمول استفاده
SASTSource Code و ساختار کددر مراحل Development
DASTApplication در حال اجرادر مراحل Testing یا Runtime
SCADependencyها و Componentهادر مراحل Build و Development

این سه روش مکمل یکدیگر هستند و هیچ‌کدام به‌تنهایی تمام نیازهای Security Testing را پوشش نمی‌دهند.

Security Testing دستی یا Automated؟ 🤖

یکی از سؤال‌های رایج این است که آیا Security Testing را باید به‌صورت دستی انجام دهیم یا با ابزارهای Automated؟

پاسخ این است که هر دو رویکرد کاربرد خودشان را دارند.

مزیت Automation

  • سرعت بالاتر در بررسی‌های تکراری
  • امکان اجرای مداوم در CI/CD
  • پوشش تعداد زیادی از موارد شناخته‌شده
  • کاهش کارهای دستی تکراری

مزیت Manual Testing

  • بررسی Business Logic
  • تحلیل رفتار Application
  • بررسی سناریوهای پیچیده
  • اعتبارسنجی Findingهای Automated Tools
  • کشف رفتارهای غیرمنتظره

بهترین رویکرد معمولاً ترکیبی از Automation و Manual Testing است.

چرا Security Scanner به‌تنهایی کافی نیست؟

فرض کنید یک Scanner روی Application اجرا شده و چند Finding گزارش کرده است.

آیا تمام این Findingها Vulnerability واقعی هستند؟

خیر.

ممکن است یک Finding:

  • False Positive باشد.
  • در Scope پروژه نباشد.
  • Impact بسیار محدودی داشته باشد.
  • نیاز به Validation دستی داشته باشد.
  • در شرایط واقعی قابل سوءاستفاده نباشد.

بنابراین نقش Tester فقط اجرای ابزار نیست؛ بلکه تحلیل، اعتبارسنجی و گزارش صحیح نتایج نیز اهمیت زیادی دارد.

چه زمانی Security Testing را انجام دهیم؟ ⏱️

یکی از رویکردهای قدیمی این بود که Security Testing را در انتهای پروژه انجام دهیم. اما در رویکردهای مدرن، بهتر است Security از مراحل ابتدایی توسعه وارد فرآیند شود.

Requirement
     ↓
Design
     ↓
Development
     ↓
Testing
     ↓
Security Checks
     ↓
Release

هرچه یک Security Issue زودتر شناسایی شود، معمولاً اصلاح آن ساده‌تر و کم‌هزینه‌تر خواهد بود.

Security Testing در چرخه CI/CD 🚀

در تیم‌هایی که از CI/CD استفاده می‌کنند، برخی Security Checkها را می‌توان در Pipeline قرار داد.

Code
  ↓
Build
  ↓
Unit Tests
  ↓
Security Checks
  ↓
Integration Tests
  ↓
Deploy

این رویکرد بخشی از مفهوم DevSecOps است؛ یعنی امنیت فقط در انتهای فرآیند بررسی نشود، بلکه در چرخه توسعه نرم‌افزار به شکل مستمر در نظر گرفته شود.

ابزارهای مهم در Security Testing برای Software Testerها 🛠️

برای شروع Security Testing لازم نیست ده‌ها ابزار مختلف یاد بگیرید. بهتر است ابتدا ابزارهایی را یاد بگیرید که بیشترین ارتباط را با کار روزمره یک Software Tester دارند.

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

1. Browser DevTools 🌐

یکی از ساده‌ترین و در عین حال کاربردی‌ترین ابزارهایی که یک Web Tester در اختیار دارد، همان Developer Tools مرورگر است.

با DevTools می‌توانید مواردی مانند موارد زیر را بررسی کنید:

  • HTTP Requestها
  • HTTP Responseها
  • Request Headerها
  • Cookieها
  • Storage
  • Network Callها
  • Response Data
  • رفتار Application در Browser

اگر هنوز با Security Testing آشنا نیستید، DevTools یکی از بهترین نقاط شروع است؛ چون بدون نیاز به نصب ابزارهای پیچیده می‌توانید رفتار Application را مشاهده کنید.

2. Postman 📮

Postman بیشتر به‌عنوان ابزار API Testing شناخته می‌شود، اما می‌تواند در Security Testing نیز بسیار کاربردی باشد.

برای مثال می‌توانید Requestهای API را تغییر دهید و رفتار Application را بررسی کنید.

  • تغییر HTTP Method
  • تغییر Parameter
  • تغییر Header
  • حذف یا تغییر Token
  • تغییر شناسه Resource
  • ارسال مقدارهای غیرمنتظره
  • مقایسه Responseهای مختلف

این قابلیت‌ها باعث می‌شوند Postman برای طراحی و اجرای Security Test Scenarioهای API مفید باشد.

3. Burp Suite 🦋

Burp Suite یکی از شناخته‌شده‌ترین ابزارها در حوزه Web Security Testing است.

یکی از مهم‌ترین قابلیت‌های آن این است که می‌تواند بین Browser و Application قرار بگیرد و HTTP Traffic را مشاهده و تحلیل کند.

Browser
   ↓
Burp Suite
   ↓
Web Application

به کمک این ابزار می‌توان Requestها را مشاهده، متوقف، تحلیل و در محیط مجاز تغییر داد.

برخی بخش‌های مهم Burp Suite عبارت‌اند از:

  • Proxy
  • Repeater
  • HTTP History
  • Decoder
  • Comparer
  • Intruder

برای یک Tester که قصد ورود جدی‌تر به Web Security Testing را دارد، یادگیری Burp Suite می‌تواند قدم مهمی باشد.

4. OWASP ZAP 🛡️

OWASP ZAP یکی دیگر از ابزارهای شناخته‌شده برای Web Security Testing است و توسط پروژه OWASP توسعه داده می‌شود.

ZAP می‌تواند برای مشاهده و تحلیل HTTP Traffic و همچنین برخی بررسی‌های امنیتی Automated مورد استفاده قرار بگیرد.

برای Testerهایی که می‌خواهند با یک ابزار رایگان و Open Source شروع کنند، ZAP می‌تواند گزینه مناسبی برای یادگیری مفاهیم Proxy و Web Security باشد.

5. Security Scanners

Security Scannerها می‌توانند Application یا Infrastructure را برای برخی الگوهای شناخته‌شده و مشکلات احتمالی بررسی کنند.

مزیت اصلی Scannerها سرعت و قابلیت Automation است؛ اما نتایج آن‌ها باید با دقت تحلیل شوند.

Scanner می‌تواند Finding پیدا کند؛ اما تصمیم‌گیری درباره اهمیت و اعتبار آن بر عهده انسان است.

Tester برای شروع با کدام ابزارها کار کند؟ 🤔

اگر در ابتدای مسیر هستید، لازم نیست همه ابزارها را هم‌زمان یاد بگیرید.

مرحلهابزار پیشنهادیهدف
شروعBrowser DevToolsشناخت HTTP و رفتار Browser
API TestingPostmanکار با API و Requestها
Web SecurityBurp Suiteتحلیل و تغییر HTTP Traffic
Web SecurityOWASP ZAPتمرین Proxy و Automated Testing
AdvancedSecurity ScannersAutomation و شناسایی Findingهای شناخته‌شده

چگونه یک Security Test Case بنویسیم؟ 📝

یکی از مهارت‌های مهم برای Software Tester این است که مفاهیم امنیتی را به Test Scenario قابل اجرا تبدیل کند.

فرض کنید Requirement این است:

User باید فقط بتواند اطلاعات Profile خودش را مشاهده کند.

به‌جای اینکه فقط Happy Path را تست کنیم، می‌توانیم سناریوهای امنیتی مختلفی طراحی کنیم.

سناریو ۱: User مجاز

Login as User A
        ↓
Request Profile A
        ↓
Expected: Profile A is returned

سناریو ۲: User غیرمجاز

Login as User A
        ↓
Request Profile B
        ↓
Expected: Access Denied

سناریو ۳: بدون Authentication

No Authentication
        ↓
Request Profile A
        ↓
Expected: Unauthorized

سناریو ۴: تغییر شناسه Resource

Request:
GET /api/profile/100

Change:
GET /api/profile/101

Expected:
User A cannot access Profile 101

این مثال نشان می‌دهد که Security Test Case الزاماً پیچیده نیست. مهم این است که Tester فقط رفتار عادی سیستم را بررسی نکند و سناریوهای سوءاستفاده احتمالی را نیز در نظر بگیرد.

چگونه یک Security Bug را گزارش کنیم؟ 🐞

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

یک Security Bug Report خوب باید تا حد امکان شامل اطلاعات زیر باشد:

  • عنوان واضح
  • شرح مشکل
  • Precondition
  • مراحل بازتولید
  • Request و Response مرتبط
  • Actual Result
  • Expected Result
  • Impact
  • Severity
  • Evidence

نمونه ساختار Bug Report

Title:
User can access another user's order

Precondition:
User A is authenticated

Steps:
1. Login as User A
2. Open User A's order
3. Change order ID
4. Send the request

Actual Result:
User A can access User B's order.

Expected Result:
User A should receive an Access Denied response.

Impact:
Unauthorized users may access other users' order information.

در گزارش‌های امنیتی، توضیح Impact اهمیت زیادی دارد؛ چون Severity یک Finding فقط به وجود داشتن یک ضعف فنی وابسته نیست و باید اثر واقعی آن نیز در نظر گرفته شود.

Severity در Security Bugها

یکی از اشتباهات رایج این است که هر Security Finding را با بالاترین Severity گزارش کنیم.

Severity باید بر اساس عواملی مانند Impact، احتمال سوءاستفاده، سطح دسترسی موردنیاز و میزان داده یا قابلیت در معرض خطر تعیین شود.

Severityنمونه کلی
Criticalدسترسی یا کنترل بسیار گسترده با Impact شدید
Highدسترسی غیرمجاز یا افشای مهم اطلاعات
Mediumریسک قابل توجه با شرایط یا محدودیت‌هایی
LowImpact محدود یا کم‌ریسک

در پروژه‌های واقعی بهتر است Severity بر اساس معیارهای مشخص سازمان یا استاندارد مورد استفاده تیم تعیین شود.

Security Regression Testing چیست؟ 🔄

وقتی یک Security Bug برطرف می‌شود، کار Tester تمام نشده است.

باید بررسی کنیم که:

  • مشکل اصلی واقعاً برطرف شده باشد.
  • سناریوی قبلی دیگر قابل بازتولید نباشد.
  • Fix باعث ایجاد مشکل جدید نشده باشد.
  • Endpointهای مشابه نیز رفتار مناسبی داشته باشند.
  • کاربران مجاز همچنان بتوانند عملیات موردنظر را انجام دهند.

بنابراین Security Regression Testing را باید بخشی از چرخه اصلاح Vulnerability در نظر گرفت.

Security Testing Checklist برای Software Tester 🔎

داشتن یک Checklist ساده می‌تواند کمک کند هنگام تست یک Feature، فقط روی رفتار Functional تمرکز نکنیم و جنبه‌های امنیتی را نیز در نظر بگیریم.

Authentication

  • آیا Login فقط با Credential معتبر امکان‌پذیر است؟
  • آیا Logout به‌درستی Session را invalidate می‌کند؟
  • آیا Session بعد از مدت مشخصی منقضی می‌شود؟
  • آیا رفتار Application بعد از تغییر Password بررسی شده است؟
  • آیا Authentication روی Endpointهای حساس نیز اعمال می‌شود؟

Authorization

  • آیا User فقط به Resourceهای مجاز دسترسی دارد؟
  • آیا Roleها Permissionهای صحیح دارند؟
  • آیا User می‌تواند Resource متعلق به User دیگری را مشاهده کند؟
  • آیا User می‌تواند عملیات مدیریتی را بدون Permission انجام دهد؟
  • آیا محدودیت‌های Authorization در Backend نیز enforce می‌شوند؟

Session

  • آیا Session Token به شکل مناسبی مدیریت می‌شود؟
  • آیا بعد از Logout، Token قبلی دیگر قابل استفاده نیست؟
  • آیا Session Expiration به‌درستی عمل می‌کند؟
  • آیا رفتار چند Session هم‌زمان مشخص و قابل پیش‌بینی است؟

Input Validation

  • آیا Inputها در Server نیز Validation می‌شوند؟
  • آیا نوع داده بررسی می‌شود؟
  • آیا مقدارهای خارج از محدوده مدیریت می‌شوند؟
  • آیا Inputهای بسیار طولانی به‌درستی مدیریت می‌شوند؟
  • آیا Application با کاراکترها و داده‌های غیرمنتظره رفتار مناسبی دارد؟

API Security

  • آیا Endpointهای حساس Authentication دارند؟
  • آیا Authorization روی هر Resource به‌درستی بررسی می‌شود؟
  • آیا اطلاعات غیرضروری در Response ارسال نمی‌شود؟
  • آیا تغییر Parameterها باعث دسترسی غیرمجاز نمی‌شود؟
  • آیا API در برابر Requestهای غیرمنتظره رفتار مناسبی دارد؟

Data Protection

  • آیا اطلاعات حساس در Response نمایش داده نمی‌شوند؟
  • آیا اطلاعات حساس در Logها ثبت نمی‌شوند؟
  • آیا اطلاعات حساس در Client Storage به شکل نامناسب ذخیره نمی‌شوند؟
  • آیا ارتباطات حساس از مسیر امن انجام می‌شوند؟

Error Handling

  • آیا Error Message اطلاعات داخلی سیستم را افشا نمی‌کند؟
  • آیا Stack Trace برای کاربر نهایی نمایش داده نمی‌شود؟
  • آیا Error Response اطلاعات غیرضروری درباره Backend ارائه نمی‌کند؟

Business Logic

  • آیا محدودیت‌های Business قابل دور زدن نیستند؟
  • آیا یک عملیات محدودشده را می‌توان چند بار اجرا کرد؟
  • آیا تغییر ترتیب Requestها باعث رفتار غیرمجاز نمی‌شود؟
  • آیا Workflowهای حساس به شکل مناسبی کنترل می‌شوند؟

اشتباهات رایج Testerها در Security Testing ⚠️

یادگیری Security Testing فقط درباره دانستن تکنیک‌ها نیست. نوع نگاه Tester نیز اهمیت زیادی دارد.

۱. فکر کنیم Security Testing یعنی فقط OWASP Top 10

OWASP Top 10 نقطه شروع بسیار خوبی است، اما تمام Security Testing نیست.

Application ممکن است مشکلاتی مانند Business Logic Flaw، ضعف Permission، Session Issue یا Information Disclosure داشته باشد که با یک Checklist ساده پیدا نشوند.

۲. فقط UI را تست کنیم 🖥️

اگر یک دکمه در UI نمایش داده نمی‌شود، به این معنی نیست که عملیات مربوط به آن در Backend نیز غیرقابل دسترس است.

Tester باید در صورت وجود API، رفتار Backend را نیز بررسی کند.

۳. فقط Status Code را بررسی کنیم

فرض کنید API پاسخ 200 OK برمی‌گرداند. این به‌تنهایی به معنی امن بودن Response نیست.

باید بررسی کنیم چه داده‌ای در Response وجود دارد و آیا User مجاز به دریافت آن داده‌ها هست یا خیر.

۴. همه Findingها را Critical گزارش کنیم 🚨

این کار می‌تواند اعتبار گزارش‌های امنیتی را کاهش دهد. Severity باید بر اساس Impact، Likelihood، Exploitability و Context تعیین شود.

۵. ابزار را جایگزین دانش کنیم 🛠️

ممکن است Tester با Burp Suite یا یک Scanner به‌خوبی کار کند، اما نداند دنبال چه چیزی است.

بهتر است ابتدا Concept را یاد بگیریم، سپس آن را به Test Scenario تبدیل کنیم و در نهایت از ابزار برای اجرای دقیق‌تر تست استفاده کنیم.

Concept
   ↓
Risk
   ↓
Test Scenario
   ↓
Tool
   ↓
Finding Analysis

۶. فقط Happy Path را بررسی کنیم

Security Testing به Exploratory Thinking نیاز دارد.

اگر مسیر معمول Application این باشد:

Login
  ↓
Create Order
  ↓
Payment
  ↓
Confirmation

باید سناریوهای دیگری را نیز در نظر بگیریم:

  • اگر Request دوباره ارسال شود چه؟
  • اگر ترتیب Requestها تغییر کند چه؟
  • اگر User Role تغییر کند چه؟
  • اگر Session منقضی شود چه؟
  • اگر شناسه Resource تغییر کند چه؟
  • اگر API مستقیماً فراخوانی شود چه؟

۷. Business Logic را فراموش کنیم

گاهی Application از نظر Authentication و Authorization درست کار می‌کند، اما Workflow آن قابل سوءاستفاده است.

برای مثال، اگر یک Coupon فقط یک بار قابل استفاده باشد، Tester باید بررسی کند که آیا با تغییر ترتیب عملیات یا تکرار یک Request می‌توان این محدودیت را دور زد یا خیر.

۸. Security Testing را فقط قبل از Release انجام دهیم

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

بهتر است Security از مراحل اولیه وارد فرآیند توسعه و Testing شود.

۹. فقط یک Role را تست کنیم 👥

اگر Application دارای Roleهای مختلف است، Security Testing بدون بررسی Permissionهای هر Role ناقص خواهد بود.

Guest
User
Manager
Admin

برای هر Role باید مشخص باشد چه Resourceهایی قابل مشاهده، ایجاد، ویرایش یا حذف هستند.

۱۰. بعد از Fix فقط همان Test را تکرار کنیم

بعد از اصلاح یک Security Bug، فقط همان سناریوی قبلی را اجرا نکنید.

بررسی کنید آیا Endpointهای مشابه، Roleهای دیگر و Workflowهای مرتبط نیز رفتار مناسبی دارند یا خیر.

چطور Security Mindset خودمان را تقویت کنیم؟ 🧠

بهترین راه برای تقویت Security Mindset این است که هنگام تست هر Feature، چند سؤال ثابت از خودمان بپرسیم.

  • چه کسی باید به این Feature دسترسی داشته باشد؟
  • چه کسی نباید دسترسی داشته باشد؟
  • اگر User ID را تغییر بدهم چه می‌شود؟
  • اگر Authentication را حذف کنم چه می‌شود؟
  • اگر Role را تغییر بدهم چه می‌شود؟
  • چه اطلاعاتی در Response برمی‌گردد؟
  • آیا می‌توان محدودیت Business را دور زد؟
  • آیا رفتار UI و API یکسان است؟

این سؤال‌ها به‌مرور باعث می‌شوند Security Testing از یک فعالیت جداگانه به بخشی از تفکر روزمره Tester تبدیل شود.

مسیر یادگیری Security Testing برای Software Tester 🚀

اگر Software Tester هستید و می‌خواهید Security Testing را شروع کنید، بهتر است مسیر یادگیری را مرحله‌به‌مرحله طی کنید.

مرحله اول: HTTP و Web را یاد بگیرید

  • HTTP Methods
  • Status Codes
  • Headers
  • Cookies
  • Sessions
  • HTTPS
  • Browser DevTools

مرحله دوم: API Testing

  • REST API
  • Request و Response
  • Authentication
  • Authorization
  • Token
  • JSON
  • Postman

مرحله سوم: مفاهیم پایه Security

  • Authentication
  • Authorization
  • Session Management
  • Access Control
  • Input Validation
  • Information Disclosure
  • Business Logic

مرحله چهارم: OWASP

در این مرحله مطالعه OWASP Top 10 و Web Security Testing Guide را شروع کنید و هر مفهوم را در یک محیط آزمایشی تمرین کنید.

مرحله پنجم: ابزارهای Security Testing

  • Burp Suite
  • OWASP ZAP
  • Browser DevTools
  • Postman

مرحله ششم: تمرین و گزارش‌دهی

یک Application آموزشی انتخاب کنید، Security Test Case طراحی کنید، تست‌ها را اجرا کنید و Findingهای خود را مانند یک Bug واقعی گزارش کنید.

Learn
  ↓
Practice
  ↓
Test
  ↓
Report
  ↓
Regression
  ↓
Repeat

یک برنامه ۳۰ روزه برای شروع Security Testing 📅

اگر بعد از خواندن این مقاله تصمیم گرفته‌اید Security Testing را جدی‌تر دنبال کنید، بهتر است یادگیری را به یک برنامه عملی تبدیل کنید.

هفته اول: Web و HTTP 🌐

  • آشنایی با HTTP و HTTPS
  • شناخت Request و Response
  • HTTP Methods
  • Status Codes
  • Headers
  • Cookies
  • Sessions
  • کار با Browser DevTools

هدف هفته اول: بتوانید یک HTTP Request را بخوانید و اجزای آن را توضیح دهید.

هفته دوم: Authentication و Authorization 🔑

  • Authentication
  • Authorization
  • Role و Permission
  • Session Management
  • Access Control
  • IDOR و BOLA

هدف هفته دوم: بتوانید یک Application دارای چند Role را از نظر Permission و Access Control بررسی کنید.

هفته سوم: Web و API Security 🧪

  • OWASP Top 10
  • API Security
  • Input Validation
  • Information Disclosure
  • Business Logic
  • Security Test Case

هدف هفته سوم: برای یک Feature بتوانید چند Security Scenario قابل اجرا طراحی کنید.

هفته چهارم: ابزار و تمرین عملی 🛠️

  • Burp Suite یا OWASP ZAP
  • Postman
  • Browser DevTools
  • Security Bug Reporting
  • Security Regression Testing

هدف هفته چهارم: یک Application آموزشی را از ابتدا تا انتها بررسی کنید و حداقل چند Finding را به شکل حرفه‌ای مستند کنید.

منابع پیشنهادی برای ادامه یادگیری 📚

Security Testing حوزه گسترده‌ای است و برای پیشرفت در آن باید مطالعه و تمرین را هم‌زمان ادامه دهید.

OWASP

OWASP یکی از مهم‌ترین منابع برای شروع و ادامه یادگیری Web Application Security است.

  • OWASP Top 10
  • OWASP Web Security Testing Guide
  • OWASP API Security
  • OWASP Cheat Sheet Series

هنگام مطالعه OWASP بهتر است فقط روی حفظ کردن نام Vulnerabilityها تمرکز نکنید. برای هر موضوع از خودتان بپرسید: «من به‌عنوان Tester چگونه می‌توانم این موضوع را تست کنم؟»

PortSwigger Web Security Academy

برای تمرین عملی Web Security، محیط‌های آموزشی اهمیت زیادی دارند. Web Security Academy مجموعه‌ای از Labهای آموزشی در حوزه Web Security ارائه می‌کند.

موضوعاتی مانند Authentication، Access Control، XSS، SQL Injection، CSRF، SSRF و Business Logic را می‌توان در محیط آموزشی تمرین کرد.

محیط‌های آزمایشگاهی

یکی از بهترین روش‌های یادگیری Security Testing، تمرین در محیط‌های عمداً آسیب‌پذیر و مجاز است.

این محیط‌ها به شما اجازه می‌دهند بدون ایجاد ریسک برای سیستم‌های واقعی، مفاهیم امنیتی را به شکل عملی تجربه کنید.

Security Testing فقط درباره ابزار نیست 🧠

ممکن است یک Tester ابزارهای قدرتمندی مانند Burp Suite و Scannerهای مختلف را بشناسد، اما اگر نداند چه چیزی را باید بررسی کند، ابزار به‌تنهایی کمک زیادی نمی‌کند.

برای همین بهتر است ترتیب یادگیری به این شکل باشد:

Concept
   ↓
Risk
   ↓
Test Scenario
   ↓
Tool
   ↓
Analysis
   ↓
Report

در واقع ابزار باید در خدمت ذهنیت Tester باشد، نه اینکه جایگزین آن شود.

از Tester به Security-Aware Tester 🚀

یادگیری Security Testing الزاماً به این معنی نیست که هر Software Tester باید به یک Penetration Tester تبدیل شود.

هدف اولیه می‌تواند بسیار ساده‌تر باشد: هنگام تست یک Feature، علاوه بر بررسی رفتار Functional، جنبه‌های امنیتی آن را نیز در نظر بگیریم.

مثلاً به‌جای اینکه فقط بپرسیم:

«آیا User می‌تواند این اطلاعات را مشاهده کند؟»

بپرسیم:

«آیا فقط User مجاز می‌تواند این اطلاعات را مشاهده کند؟»

همین تغییر کوچک در نوع سؤال پرسیدن، می‌تواند کیفیت Security Testing را به شکل قابل توجهی افزایش دهد.

Security Testing؛ یک مهارت مکمل برای Tester

یک Software Tester حرفه‌ای فقط بررسی نمی‌کند که Application درست کار می‌کند یا نه.

او باید بتواند رفتار Application را از زوایای مختلف بررسی کند:

  • آیا درست کار می‌کند؟
  • آیا برای User درست کار می‌کند؟
  • آیا Permissionها درست اعمال شده‌اند؟
  • آیا اطلاعات فقط در اختیار افراد مجاز قرار می‌گیرند؟
  • آیا محدودیت‌های Business قابل دور زدن نیستند؟
  • آیا API و Backend محدودیت‌های امنیتی را enforce می‌کنند؟

این نگاه باعث می‌شود Testing از اجرای صرف Test Caseها فراتر برود و به تحلیل واقعی رفتار Application نزدیک شود.

حرف آخر 🎯

Security Testing مهارتی نیست که با خواندن یک مقاله یا حفظ کردن فهرستی از Vulnerabilityها به دست بیاید.

این مهارت به‌مرور و از طریق دانش، تمرین، مشاهده، تحلیل و پرسیدن سؤال‌های درست شکل می‌گیرد.

برای شروع لازم نیست متخصص امنیت باشید.

  • HTTP را یاد بگیرید.
  • API Testing را تمرین کنید.
  • Authentication و Authorization را درک کنید.
  • OWASP Top 10 را مطالعه کنید.
  • با یک Proxy مانند Burp Suite یا OWASP ZAP کار کنید.
  • Security Test Case طراحی کنید.
  • Findingهای خود را حرفه‌ای گزارش کنید.
  • در محیط‌های آموزشی تمرین کنید.

و مهم‌تر از همه، هنگام Testing همیشه یک سؤال را همراه خود داشته باشید:

اگر قرار بود از این Feature سوءاستفاده کنم، چه چیزی را امتحان می‌کردم؟

همین سؤال ساده می‌تواند شروع مسیر شما از یک Software Tester به یک Security-Aware Tester باشد. 🔐🚀

یادگیری Security Testing را از امروز شروع کنید؛ لازم نیست همه‌چیز را بدانید، کافی است هر بار یک سؤال امنیتی بیشتر بپرسید.

سؤالات متداول درباره Security Testing ❓

آیا هر Software Tester باید Security Testing بلد باشد؟

لازم نیست هر Software Tester به یک Security Specialist یا Penetration Tester تبدیل شود؛ اما آشنایی با مفاهیم پایه Security Testing می‌تواند کیفیت تست‌ها را افزایش دهد. شناخت Authentication، Authorization، Access Control، Session و Input Validation برای بسیاری از Testerها بسیار کاربردی است.

تفاوت Security Testing و Penetration Testing چیست؟

Security Testing یک مفهوم گسترده است و روش‌های مختلفی برای ارزیابی امنیت Application و سیستم را شامل می‌شود. Penetration Testing یکی از رویکردهای تخصصی‌تر است که با هدف شناسایی و اعتبارسنجی قابلیت سوءاستفاده از ضعف‌های امنیتی انجام می‌شود.

آیا برای شروع Security Testing باید برنامه‌نویسی بلد باشیم؟

برای شروع Security Testing در سطح Software Tester، تسلط کامل بر برنامه‌نویسی الزامی نیست. با این حال، آشنایی با مفاهیم پایه Programming، HTTP، API، Database و نحوه کار Application کمک زیادی به تحلیل مشکلات امنیتی می‌کند.

آیا یادگیری Burp Suite برای Software Tester ضروری است؟

ضروری نیست، اما برای Testerهایی که قصد دارند وارد Web Security Testing شوند، یادگیری Burp Suite بسیار مفید است. این ابزار در مشاهده و تحلیل HTTP Traffic و طراحی سناریوهای امنیتی کاربرد زیادی دارد.

آیا Security Testing فقط برای Web Application است؟

خیر. Security Testing می‌تواند برای Web Application، API، Mobile Application، Desktop Application، Infrastructure و سایر اجزای یک سیستم نرم‌افزاری انجام شود. با این حال، Web و API Security برای بسیاری از Software Testerها نقطه شروع مناسبی هستند.

از کجا Security Testing را شروع کنیم؟

بهتر است ابتدا HTTP و مفاهیم Web را یاد بگیرید، سپس سراغ API Testing، Authentication، Authorization، Access Control و OWASP بروید. بعد از آن می‌توانید کار با ابزارهایی مانند Burp Suite یا OWASP ZAP را شروع کنید و آموخته‌های خود را در محیط‌های آموزشی تمرین کنید.

چک‌لیست سریع Security Testing برای Testerها ✅

اگر بخواهیم تمام مقاله را در یک Checklist کوتاه خلاصه کنیم، هنگام تست یک Feature این سؤال‌ها را از خودمان بپرسیم:

  • آیا کاربر احراز هویت شده است؟
  • آیا کاربر مجوز انجام این عملیات را دارد؟
  • آیا کاربر می‌تواند به Resource کاربر دیگری دسترسی پیدا کند؟
  • آیا API محدودیت‌های امنیتی را رعایت می‌کند؟
  • آیا اطلاعات حساس در Response افشا می‌شوند؟
  • آیا Session به شکل مناسبی مدیریت می‌شود؟
  • آیا Inputهای غیرمنتظره به‌درستی مدیریت می‌شوند؟
  • آیا محدودیت‌های Business Logic قابل دور زدن هستند؟
  • آیا Error Message اطلاعات حساس افشا می‌کند؟
  • آیا بعد از Fix، Security Regression Testing انجام شده است؟

جمع‌بندی مقاله

Security Testing یکی از مهارت‌هایی است که می‌تواند دید یک Software Tester را نسبت به Application تغییر دهد. در این رویکرد، Tester فقط بررسی نمی‌کند که Feature طبق Requirement کار می‌کند؛ بلکه بررسی می‌کند آیا Feature در برابر استفاده غیرمجاز، دستکاری داده و سناریوهای غیرمنتظره نیز رفتار مناسبی دارد یا خیر.

برای شروع، لازم نیست سراغ مباحث بسیار پیچیده بروید. یادگیری HTTP، API، Authentication، Authorization، Access Control و OWASP می‌تواند پایه مناسبی ایجاد کند. سپس با تمرین در محیط‌های آزمایشی و استفاده از ابزارهایی مانند Burp Suite و OWASP ZAP می‌توانید دانش خود را به مهارت عملی تبدیل کنید.

در نهایت، مهم‌ترین چیزی که یک Tester برای ورود به Security Testing نیاز دارد، فقط ابزار یا دانش فنی نیست؛ بلکه Security Mindset است.

یک Tester امنیتی خوب فقط می‌پرسد «آیا سیستم کار می‌کند؟»؛ بلکه می‌پرسد «آیا سیستم فقط برای فرد و شرایط مجاز کار می‌کند؟» 🔐

مسیر بعدی یادگیری شما 🚀

اگر این مقاله نقطه شروع شما در Security Testing است، پیشنهاد می‌کنیم مسیر یادگیری را به ترتیب زیر ادامه دهید:

  1. HTTP و HTTPS
  2. API Testing
  3. Authentication و Authorization
  4. Session Management
  5. Access Control
  6. OWASP Top 10
  7. OWASP Web Security Testing Guide
  8. Burp Suite یا OWASP ZAP
  9. Security Bug Reporting
  10. تمرین در Labهای آموزشی

این مسیر را مرحله‌به‌مرحله طی کنید و سعی کنید هر مفهوم را با یک سناریوی واقعی یا آزمایشگاهی تمرین کنید. در Security Testing، تمرین کردن بسیار مهم‌تر از صرفاً مطالعه کردن است. 🧠

طبقه بندی شده در:

تست نرم افزار,

اخرین بروزرسانی: مرداد 22, 1405