یک سیستم امنیت سایبری فقط به اندازه ضعیفترین حلقه خود امن است. مصرفکنندگان و توسعهدهندگان احتمالاً هیچ دلیلی نداشتند که به امنیت یک API فینتک که توسط بیشتر بزرگترین بانکهای جهان، مؤسسات مالی رسمی، و اکثریت نرمافزارها و خدمات مالی پرکاربرد بازار استفاده میشود، شک کنند.
متأسفانه، این اعتبار و اعتماد به شرکای تجاری و ارائهدهندگان شخص ثالثی که از APIهای Open Banking استفاده میکنند نیز تعمیم داده میشود — ارائهدهندگانی که همیشه سختگیرانهترین بهترین شیوههای امنیت سایبری را رعایت نمیکنند. این اعتماد بیشازحد میتواند به رخدادهای فاجعهبار امنیت سایبری منجر شود؛ رخدادهایی مانند نشت داده Okta در اکتبر ۲۰۲۳ که اطلاعات حساس ۱۸٬۴۰۰ مشتری Okta را افشا کرد.
حادثه امنیت سایبری Okta بهطور غیرمستقیم با API Open Banking در ارتباط بود، زیرا ناشی از افشای نادرست داراییهای احراز هویتشده مانند توکنهای کاربری بود، اما با این حال یک آسیبپذیری بالقوه را آشکار میکند.
این آسیبپذیری میتواند پیامدهای بزرگی به همراه داشته باشد، بهویژه با توجه به اینکه فقط در بریتانیا بیش از ۱۵ میلیون مشتری از ابزارها و نرمافزارهایی استفاده میکنند که در آنها API Open Banking دخیل است.
پذیرش و استفاده از Open Banking همچنان در حال گسترش است و با نرخ رشد مرکب سالانهای در حدود ۲۳.۳٪ افزایش مییابد. با رشد Open Banking، ضروری است که هرگونه مسئله امنیتی بالقوه را پیش از آنکه به حفرههای عمیق در سیستمهای امنیت سایبری ما تبدیل شوند، برطرف کنیم.
در سپتامبر ۲۰۱۶، نهاد پیادهسازی Open Banking (Open Banking Implementation Entity یا OBIE) API حساب و تراکنش Open Banking را با هدف استانداردسازی تراکنشهای مالی منتشر کرد، در حالی که همزمان رقابت و شفافیت را از طریق توانمندسازی ارائهدهندگان شخص ثالث حفظ میکرد.
این اقدام جسورانه بود و نیت درستی داشت، اما محدودیتهایی نیز دارد. بسیاری از پژوهشگران و تحلیلگران امنیت سایبری معتقدند که API حساب و تراکنش Open Banking دارای برخی آسیبپذیریهاست، حتی اگر این آسیبپذیریها در نگاه اول آشکار نباشند.
این موضوع نخستینبار در مارس ۲۰۲۰ توسط پژوهشگران Abdulaziz Almehrej، Leo Freitas، Paolo Modesti و Qudus Shotomiwa در قالب یک پیشچاپ برای آرشیو ArXiv با عنوان
«Security Analysis of the Open Banking Account and Transaction API Protocol»
منتشر شد. این مقاله وجود آسیبپذیریهای متعدد در سطح API را گزارش میکند. برخی از ریسکهای مشکوک شامل مشکلاتی در احراز هویت، مجوزدهی و محرمانگی هستند.
از آن زمان، پژوهشگران و تحلیلگران امنیت سایبری متعددی بر پایه این گزارش اولیه کار کردهاند تا این ریسکها را با جزئیات بیشتری بررسی کرده و در عین حال برخی راهکارهای بالقوه را نیز ارائه دهند.
اکنون که مقاله «Security Analysis of the Open Banking Account and Transaction API Protocol» سرانجام در شماره دسامبر ۲۰۲۵ مجله Cyber Security and Applications بهطور رسمی منتشر میشود، زمان مناسبی به نظر میرسد که پروتکل API حساب و تراکنش Open Banking را با توجه به پژوهشهایی که در پنج سال گذشته انجام شدهاند، دوباره مورد بررسی قرار دهیم.
پروتکل API حساب و تراکنش Open Banking چیست؟
پیش از آنکه عمیقتر وارد پژوهشها شویم، بیایید برای لحظهای مکث کنیم و اصطلاحات خود را دقیق تعریف کنیم.
پروتکل API حساب و تراکنش Open Banking دقیقاً چیست؟
پروتکل API حساب و تراکنش Open Banking بهعنوان سنگبنای تمام تعاملپذیری مالی مدرن در نظر گرفته شده است.
این پروتکل با استفاده از چارچوبهای مقرراتی مانند استاندارد Open Banking بریتانیا و استاندارد PSD2 (Payment Services Directive 2) اتحادیه اروپا طراحی شده است و به ارائهدهندگان شخص ثالث (Third-Party Providers یا TPPs) اجازه میدهد به دادههای بانکی مصرفکنندگان از مؤسسات مالی مانند Santander یا Barclays Bank در بریتانیا یا HSBC Holdings در اروپا دسترسی پیدا کنند و به نمایندگی از کاربر تراکنشهای مالی انجام دهند.
برای دستیابی به این هدف، این پروتکل مشخص میکند که چگونه ارائهدهندگان خدمات پرداختِ نگهدارنده حساب (Account Servicing Payment Service Providers یا ASPSPs) مانند بانکها، APIهای RESTful را در معرض دسترس قرار میدهند تا TPPها بتوانند جزئیات حساب، ماندهها و تاریخچه تراکنشها را بازیابی کنند یا پس از دریافت رضایت صریح کاربر، پرداختها را آغاز نمایند.
امنیت از طریق یک فرایند احراز هویت لایهای اعمال میشود که شامل احراز هویت قوی مشتری (Strong Customer Authentication یا SCA)، جریانهای مجوزدهی OAuth 2.0 و TLS دوجانبه (mTLS) برای امنیت انتقال است.
هم توکنهای دسترسی (access tokens) و هم توکنهای تازهسازی (refresh tokens) استفاده میشوند تا اطمینان حاصل شود که دسترسی به دادهها محدود به دامنه مشخص، زماندار، و وابسته به یک نشست رضایت خاص است.
تحلیل امنیتی پروتکل API حساب و تراکنش Open Banking: بررسی اولیه
در تئوری، این APIها مقاوم و امن هستند. اما در عمل، داستان متفاوت است. مقاله «Security Analysis of the Open Banking Account and Transaction API Protocol» مشکلات متعددی را در طراحی این پروتکل گزارش میکند.
خوشبختانه، این مقاله در نهایت نتیجهگیری میکند که بیشتر این ریسکها را میتوان با پیروی سختگیرانه از جدیدترین بهترین شیوهها در حوزه امنیت سایبری API کاهش داد.
بهطور خاص، پژوهشگران بهشدت توصیه میکنند که جدیدترین بهترین شیوهها در زمینه شناسههای نشست (session identifiers) رعایت شود و از استفاده مجدد از توکنها اجتناب گردد.
پژوهشهای بعدی محدودیتهای بیشتری از این تحلیل امنیتی را آشکار میکنند.
وایتپیپر سال ۲۰۲۴ با عنوان «API Security in the Open Banking Ecosystem» از Akamai نشان میدهد که پروتکل Transaction API نهتنها دارای این آسیبپذیریهاست، بلکه در برابر برخی از آسیبپذیریهای رایج امنیت سایبری که معمولاً APIها را تهدید میکنند نیز آسیبپذیر است.
مسائلی مانند Broken Object-Level Authorization (BOLA)، نشت توکن، و دور زدن محدودیت نرخ درخواست (rate limiting) میتوانند در نتیجه پیادهسازی نادرست پروتکل Transaction API، انتشار ضعیف هویت، یا مدیریت نامناسب خطاها رخ دهند.
اکنون که درک محکمتری از تحلیل امنیتی پروتکل API حساب و تراکنش Open Banking داریم، بیایید به برخی از دانشها و خردی که طی پنج سال گذشته شکل گرفتهاند نگاه کنیم؛ دانشی که میتواند به شما در ایمنسازی APIهای Open Banking کمک کند.
چگونه API حساب و تراکنش Open Banking را ایمن کنیم
بستن رضایت، بستن توکن و یکپارچگی نشست
تقریباً تمام پژوهشهای انجامشده درباره تحلیل امنیتی پروتکل API حساب و تراکنش Open Banking به این نتیجه میرسند که اگر میخواهید API Open Banking شما امن باشد، بستن رضایت (consent binding) باید اعمال شود.
این به این معناست که رضایت کاربر و توکنها باید در سراسر نشست بهطور کامل و دقیق به یکدیگر متصل باقی بمانند.
بینظمیهای جزئی مانند پیکربندی نادرست URIهای بازگشت (redirect URIs) یا دامنهبندی ناکافی توکنها میتوانند به خطای بستن رضایت یا جایگزینی توکن منجر شوند.
برای خنثیسازی این تهدید، OWASP Transaction Authorization Cheat Sheet توصیه میکند از دامنههای ریزدانه توکن، اعتبارسنجی nonce، و توکنهای تراکنش یکبارمصرف استفاده شود تا از حملات replay یا استفاده مجدد غیرمجاز جلوگیری گردد.
پایاننامهای از دانشگاه Linköping با عنوان Security Evaluation of Open Banking Authentication Flows نیز این دیدگاه را تأیید میکند و نشان میدهد که ابزارهای واسط مانند API gatewayها چگونه میتوانند بهطور ناخواسته اعتبارنامههای API را افشا کنند.
در کنار هم، این منابع نشان میدهند که رضایت، توکنها و یکپارچگی نشست چگونه با یکدیگر کار میکنند تا یکی از سنگبناهای اصلی امنیت سایبری APIهای Open Banking را شکل دهند.
مراقب مجوزدهی شکسته در سطح شیء و کنترل دسترسی منابع باشید
هم وایتپیپر Akamai در سال ۲۰۲۴ و هم فهرست OWASP API Security Top 10، مجوزدهی شکسته در سطح شیء (BOLA) را بهعنوان رایجترین بردار حمله علیه APIها معرفی میکنند؛ جایی که مهاجمان با تغییر منابع مجاز، اندپوینتهای شناختهشده را بمباران میکنند.
این یکی از مواردی است که API Open Banking میتواند یک شبکه را ناامنتر کند، زیرا یک چیدمان استاندارد را الزام میکند. برای کاهش این ریسک، تحلیلگران و پژوهشگران بر لزوم منطق مجوزدهی چندلایه (defense-in-depth)، اتصال شناسه منابع به توکنهای مختص کاربر، و اعتبارسنجی هر دسترسی در سطح سرور تأکید میکنند.
از فرضیات درباره پیادهسازی اجتناب کنید
گزارشهای اولیهای که امنیت و پایداری APIهای Open Banking را اعلام میکردند، فرض را بر این گذاشته بودند که هر API از یک کانال ارتباطی پاک و سرتاسری بین ASPSP و TPP استفاده میکند که با mTLS ایمن شده است.
پژوهش سال ۲۰۲۵ دانشگاه Linköping نشان میدهد که بسیاری از مصرفکنندگان API از مجموعهای پیچیده از API gatewayها، load balancerها، proxyها و لایههای مدیریت API استفاده میکنند.
دروازههای نادرست پیکربندیشده و گواهیهای منقضیشده میتوانند مشکلاتی ایجاد کنند که از دید اقدامات امنیتی سطح بالا پنهان میمانند.
به همین دلیل، متخصصان امنیت سایبری اصرار دارند که API gatewayها باید بخشی از روال امنیتی باشند.
چرخش منظم گواهیها، اعتبارسنجی اندپوینتها و ثبت لاگ رفتار gatewayها اکنون بهعنوان الزامات اساسی در نظر گرفته میشوند.
پایش و شاخصهای عملیاتی بهعنوان سیگنالهای امنیتی
داشبوردهای عملیاتی Open Banking UK بهشکلی غیرمنتظره برای تقویت امنیت API مفید هستند. اگرچه این داشبوردها بهطور خاص برای امنیت طراحی نشدهاند، اما طیف وسیعی از شاخصها را در صدها مؤسسه پایش میکنند. این ویژگی آنها را برای شناسایی و محافظت در برابر رفتارهای غیرعادی مانند فراخوانیهای مشکوک تجاری یا افزایش ناگهانی ترافیک ایدهآل میسازد.
برای محافظت در برابر ترافیک غیرعادی، از داشبوردهای عملیاتی برای ایجاد یک خط پایه از وضعیت عادی استفاده کنید و سپس از آن خط پایه برای فعالسازی هشدار در صورت بروز رفتار غیرمنتظره بهره بگیرید.
همراستایی مقرراتی و حاکمیت
مقاله سال ۲۰۲۴ با عنوان Harmonizing Open Banking in the European Union تأکید میکند که امنیت در Open Banking فقط یک مسئله فنی نیست، بلکه یک چالش حاکمیتی نیز هست.
PSD2 و چارچوب Open Banking بریتانیا احراز هویت قوی، مدیریت رضایت و گزارشدهی رخدادها را الزام میکنند، اما در عین حال فرایندهای صدور گواهی را نیز تعریف میکنند تا اطمینان حاصل شود TPPها و ASPSPها به کنترلهای استاندارد پایبند هستند.
تمرکز بر حاکمیت، برخی آسیبپذیریها را آشکار میکند که در غیر این صورت ممکن است پنهان بمانند.
بهطور خاص، مؤسسات مختلف ممکن است اصطلاحات فنی مانند «کنترل دسترسی به داده» را به شیوههای متفاوتی تعریف کنند.
این مقاله از اصول security-by-design که در دل مقررات نهادینه شدهاند دفاع میکند؛ اصولی که در آن بهروزرسانی پروتکلها، ممیزیها و چرخههای صدور گواهی همگام با اطلاعات تهدید بهطور مداوم تکامل مییابند.
جمعبندی نهایی درباره API حساب و تراکنش Open Banking
در پنج سال گذشته، امنیت سایبری APIهای Open Banking از یک بحث نظری به یک چالش عملی تبدیل شده است.
اگرچه این فرایند گاهی آزاردهنده است، اما در واقع چیز خوبی محسوب میشود، زیرا موارد لبهای مبهم و سایههای پیشبینینشده را آشکار میکند. دانستن اینکه شکستهای زره امنیت سایبری کجا ممکن است رخ دهند، بسیار ارزشمند است.
ترکیب این بینشها با جدیدترین بهترین شیوههای پیشرفته در زمینه کنترل دسترسی و مدیریت هویت، بیشتر این نگرانیها را برطرف میکند و ذهن شما را آزاد میسازد تا روی چیزی تمرکز کنید که واقعاً اهمیت دارد — ساخت بهترین ابزارها و نرمافزارهای مالی ممکن و خدمترسانی بهتر به مشتریان.
