اپلیکیشن شما روی دستگاهی اجرا میشود که کنترلش با شما نیست. ما همان کاری را می‌کنیم که مهاجم میکند: اپ را باز می‌کنیم، ترافیکش را می‌خوانیم و API پشت آن را می‌آزماییم — جایی که معمولاً یافته‌های واقعی آنجاست.
ارزیابی بر پایه‌ی استاندارد OWASP MASVS و راهنمای تست MASTG انجام میشود.
پیش از فهرست، یک چیز را صریح بگوییم چون بر تصمیم شما اثر دارد: در اکثر پروژه‌های موبایل، یافته‌های با شدت بالا در خودِ اپ نیستند؛ در API پشت آن هستند. اپلیکیشن موبایل عمدتاً یک لایه‌ی نمایش است که با یک سرویس وب حرف می‌زند. آنچه واقعاً می‌تواند دادهی همهی کاربران را افشا کند یا موجودی حساب را تغییر دهد، معمولاً یک نقطه‌ی انتهایی است که مجوزدهی را در سمت سرور بررسی نمی‌کند.
و این خبر خوبی برای شماست: آن API یک برنامه‌ی وب است و تست نفوذ وب تخصص اصلی ماست. در ارزیابی موبایل، بخش قابل‌توجهی از زمان صرف آزمون همان سرویس پشتیبان میشود — کنترل دسترسی در سطح شیء، اعتبارسنجی توکن، منطق کسبوکار و شرایط رقابتی در تراکنش‌ها.
باور غلط رایج: «اپ ما مبهم‌سازی (Obfuscation) شده، پس امن است.» مبهم‌سازی هزینه‌ی مهندسی معکوس را بالا می‌برد اما آن را غیرممکن نمی‌کند و هیچ تأثیری بر امنیت سمت سرور ندارد. همین‌طور Certificate Pinning: رهگیری ترافیک را برای مهاجم معمولی سخت میکند، ولی روی دستگاه تحت کنترل مهاجم قابل دور زدن است. هر دو لایه‌ی مفیدی‌اند، اما هیچ‌کدام جای اعتبارسنجی سمت سرور را نمی‌گیرند.
بررسی آنچه اپ روی دستگاه می‌نویسد: توکن و رمز در SharedPreferences یا فایل‌های محلی، پایگاه دادهی رمزنگاری‌نشده، لاگ‌های حساس و نسخه‌های پشتیبان قابل استخراج.
همچنین بررسی میشود که آیا از Keystore اندروید و Keychain در iOS به‌درستی استفاده شده، آیا دادهی حساس در حافظه‌ی پنهان تصاویر و اسکرین‌شات سیستم باقی می‌ماند، و آیا نشست پس از خروج کاربر واقعاً در سمت سرور باطل میشود یا فقط توکن محلی پاک میشود.
رهگیری ترافیک اپ، بررسی پیاده‌سازی TLS و Certificate Pinning، و تست کامل API پشت اپ — جایی که بیشتر آسیب‌پذیری‌های جدی پیدا میشوند.
روی API، همان متدولوژی تست وب اجرا میشود: آیا کاربر الف می‌تواند با تغییر شناسه به دادهی کاربر ب برسد (IDOR)؟ آیا نقاط انتهایی مدیریتی فقط در اپ پنهان شده‌اند یا واقعاً در سرور محافظت میشوند؟ توکن‌ها چه عمری دارند و آیا ادعاهای JWT درست اعتبارسنجی میشوند؟
دی‌کامپایل اپ برای یافتن کلیدهای API و اسرار جاسازی‌شده در کد، بررسی مبهم‌سازی (Obfuscation) و امکان دستکاری و انتشار مجدد نسخه‌ی تغییریافته.
نکته‌ی تعیین‌کننده این است که هر چیزی که در بسته‌ی نصبی باشد، در اختیار مهاجم است. پرسش درست این نیست که «چقدر پیدا کردنش سخت است»، بلکه این است که «اگر پیدا شد، چه اتفاقی می‌افتد» — و پاسخ باید «هیچ اتفاق مهمی» باشد.
مجوزهای بیش از نیاز، کامپوننت‌های صادرشده‌ی اندروید، Deep Linkهای ناامن، ضعف در تشخیص روت/جیلبریک و نشت داده از طریق کلیپ‌بورد و اسکرین‌شات.
در اپ‌هایی که از WebView استفاده میکنند، پیکربندی WebView و پلهای جاوااسکریپت-به-نیتیو هم بررسی میشود؛ این پل‌ها در صورت پیکربندی نادرست می‌توانند یک XSS ساده را به دسترسی سطح دستگاه تبدیل کنند.
آزمون کامل سرویس وب پشت اپ با همان متدولوژی تست نفوذ وب: احراز هویت و ثبت‌نام، بازیابی رمز، کنترل دسترسی افقی و عمودی، محدودسازی نرخ و منطق کسبوکار.
این بخش معمولاً بیشترین سهم را در یافته‌های بحرانی دارد و دقیقاً همان کاری است که در تست نفوذ وب انجام می‌دهیم.
پنج گام، با مجوز کتبی و محدوده‌ی مکتوب پیش از شروع. آزمون روی دستگاههای تحت کنترل ما اجرا میشود، نه روی دستگاه کاربران واقعی.
پرسش‌هایی که تیم‌های محصول پیش از سفارش ارزیابی اپ می‌پرسند.
الزامی نیست — تست جعبه سیاه فقط با فایل نصبی هم انجام میشود. اما دسترسی به سورس (جعبه سفید) پوشش را عمیقتر و زمان را کوتاهتر میکند.
بله. حتی اپهای مبتنی بر WebView مشکلات خاص خود را دارند: پیکربندی ناامن WebView، ذخیرهی توکن روی دستگاه و پلهای جاوااسکریپت-به-نیتیو.
خیر. تست API پشت اپ بخش جدانشدنی ارزیابی موبایل است — بیشتر یافته‌های بحرانی دقیقاً همان‌جا هستند. اگر همان API به وب‌اپلیکیشن شما هم سرویس می‌دهد، منطقی‌تر است از ابتدا یک تست نفوذ وب با پوشش کامل سفارش دهید و ارزیابی موبایل را به‌عنوان لایه‌ی اضافه روی آن ببینید.
بستگی دارد. اگر هر دو نسخه از یک پایگاه کد مشترک (React Native، Flutter) ساخته شده‌اند و با همان API حرف می‌زنند، بخش عمده‌ی یافته‌ها مشترک است و می‌توان یک پلتفرم را کامل و دیگری را هدفمند آزمود. اگر دو تیم جداگانه دو اپ نیتیو نوشته‌اند، تفاوت‌ها معنادار است — به‌ویژه در ذخیره‌سازی محلی و تعامل با پلتفرم — و هر دو باید بررسی شوند.
مفید است اما نباید کنترل امنیتی اصلی شما باشد. هر مکانیزم تشخیص روت روی دستگاهی که در اختیار مهاجم است قابل دور زدن است؛ ارزش واقعی آن، افزایش هزینه‌ی حمله و کاهش خطر برای کاربران عادیِ دستگاه آلوده است. اگر امنیت اپ شما به این تشخیص وابسته باشد، عملاً هیچ امنیتی ندارید — چون همهی تصمیم‌های حساس باید در سمت سرور گرفته شوند.
یک اپ متعارف با یک نقش کاربری و API محدود معمولاً حدود یک هفته‌ی کاری زمان می‌برد؛ اپهای مالی یا چندنقشه با API گسترده، دو تا سه هفته. خروجی، گزارش دوسطحی است: خلاصه‌ی مدیریتی و بخش فنی با گام‌های بازتولید، شواهد، شماره‌ی CWE، شدت CVSS و راهکار رفع — به‌همراه یک دوره تست مجدد پس از انتشار نسخه‌ی اصلاح‌شده.
حمله به فروشگاههای اپ، به زیرساخت گوگل یا اپل، و به سرویسهای شخص ثالثی که مجوز آنها را ندارید، خارج از دامنه است. همچنین آزمون روی دستگاه یا حساب کاربران واقعی انجام نمیشود؛ همهی آزمونها روی دستگاههای آزمایشی و حسابهای تست اجرا میشوند. آزمونهای اختلالزا و بارگذاری سنگین هم بهصورت پیشفرض خارج از محدودهاند.
نه لزوماً همهی اپ؛ اما هر تغییر در احراز هویت، پرداخت یا مدیریت دادهی حساس باید ارزیابی هدفمند شود. تغییر در API معمولاً مهمتر از تغییر در رابط کاربری است، چون همانجاست که کنترل دسترسی و منطق کسبوکار زندگی میکنند. قاعدهی عملی: ارزیابی کامل سالانه، بهعلاوهی ارزیابی هدفمند پس از هر تغییر در قابلیتهای حساس.
ارزیابی امنیتی اپ اندروید و iOS با متدولوژی OWASP MASVS — به‌همراه آزمون کامل API پشت اپ، جایی که بیشتر یافته‌های بحرانی آنجاست.