رعایت نکات امنیتی به عنوان بخش لاینفک توسعهٔ هر نوع نرم‌افزاری است و طراحی RESTful API نیز از این قاعده مستثنی نیست که در ادامه برخی از مهم‌ترین آن‌ها را برخواهیم شمرد:
Least Privilege
زمانی که اقدام به عرضهٔ ای‌پی‌آی می‌کنیم، پرمیشن (مجوز) می‌باید حداقلی باشد؛ به عبارت، مادامی که کاربر ای‌پی‌آی نیاز به مجوز خاصی ندارد، لزومی به عرضهٔ آن نیست چرا که هرچه وی پرمیشن‌های بیشتری داشته باشد، احتمال بروز رفتاری غیرقابل‌انتظار از وی بیشتر خواهد شد.
Fail-Safe Defaults
سطح دسترسی کاربران به هر ریسورسی در سمت سرور به صورت پیش‌فرض می‌باید مسدود باشد.
Economy of Mechanism
تا حد ممکن معماری ای‌پی‌آی می‌باید ساده باشد چرا که هر گونه پیچیدگی می‌تواند در نهایت منجر به خطاپذیری سرویس گردد.
Complete Mediation
سرویس هرگز نباید بر مبنای دیتای کَش‌شده سطح دسترسی‌ها را مدیریت کند.
Least Common Mechanism
اشتراک‌گذاری وضعیت (State) مابین لایه‌های مختلف منجر به کاهش امنیت می‌گردد زیرا اگر به طور مثال سهواً در یکی از لایه‌ها پرمیشنی که نباید به کاربر داده شود، در دیگر لایه‌ها نیز کاربر به چیزی که نباید دسترسی خواهد داشت.
آشنایی با تفاوت‌های Authentication و Authorization
Authentication به این پروسه اشاره دارد که یک درخواست از سمت سیستمی است که از دید وب سرورمان معتبر است و آن سیستم همانی است که ادعا می‌کند اما Authorization به این نکته اشاره دارد که آیا یک سرویس (درخواست‌دهنده) پرمیشن‌های لازم برای عملی کردن یک تَسک را دارا است یا خیر.
فرآیندهای فوق بدین شکل است که ابتدا به ساکن کلاینت یک ریکوئست ارسال می‌کند که معمولاً حاوی توکنی است که مشخص می‌سازد درخواست‌دهنده کیست و وب سرور دریافت‌کنندهٔ آن درخواست نیز بر اساس توکن دریافتی مشخص می‌سازد که آیا درخواست‌دهنده معتبر است یا خیر. در نهایت، اگر درخواست‌دهنده پرمیشن (مجوز) لازم را داشته باشد، پاسخی مرتبط با درخواست‌اش دریافت خواهد کرد.
معمولاً امروزه از OAuth برای پروسهٔ Authentication استفاده می‌شود اما در عین حال سرویس‌های دیگری نیز هستند که برای این منظور می‌توانند مورد استفاده قرار گیرند که از آن جمله می‌توان به OpenID اشاره کرد.
حال در ادامه نکاتی را مطرح خواهیم نمود که در نهایت منجر به ارتقاء ضریب امنیتی ای‌پی‌آی خواهند شد که عبارتند از:
استفاده از پروتکل امن HTTPS
نیاز به توضیح نیست که HTTPS منجر به ارتقاء امنیت تبادل داده‌ها مابین کلاینت و سرور می‌گردد که در همین راستا توصیه می‌کنیم به آموزش درآمدی بر پروتکل امن HTTPS مراجعه نمایید.
هَش کردن پسوردها
پس هَش کردن کلیهٔ اطلاعات حساس کاربران همچون پسوردهای ایشان، می‌توانیم این تضمین را ایجاد کنیم که اگر بنا به هر دلیلی سیستم لو رفت، داده‌های کاربران ناخوانا خواهند بود که در این ارتباط توصیه می‌کنیم به مقالات زیر مراجعه نمایید:
- رمزنگاری (Cryptography) چیست؟
- آشنایی با انواع متدهای رمزگذاری پسورد
- آشنایی با تفاوت‌های Hashing ،Encrypting ،Encoding و Obfuscation
عدم درج اطلاعات حساس در یوآرال
تحت هیچ عنوان دیتایی همچون پسورد، سِشِن توکن و چیزهایی از این دست را نمی‌باید به عنوان پارامتر در یوآرال ارسال کرد به طوری که مثلاً داریم:
http://api.example.com/user-management/users/{id}/someAction?apiKey=abcd123456789 در واقع، در این صورت داده‌ها در لاگ‌های سرور ذخیره شده و احتمال دارد که مورد حمله قرار گیرند.
در نظر گرفتن Timestamp در حین ارسال درخواست
یکی از انواع حملاتی که ممکن است روی وب سرویس‌ها اِعمال گردد Brute Force است که به منظور افزودن یک لایهٔ امنیتی به وب سرویس خود می‌توان در کلیهٔ ریکوئست‌ها از یک Timestamp استفاده نمود. با افزودن این پارامتر، هر دفعه که درخواستی برای سرور ارسال می‌گردد، می‌توان تایم فعلی را با تایم درج‌شده در ریکوئست مقایسه کرده و صرفاً اجازهٔ هندل شدن درخواست‌هایی را داد که در یک بازه زمانی معقول (مثلاً ۱ الی ۲ دقیقه) هستند. این کار جلوی حملات ساده‌ای که در آن هکر بدون تغییر تایم‌اِستمپ قصد دارد تا درخواست‌های تکراری به سمت سرور ارسال کند را می‌گیرد.
اعتبارسنجی پارامترها
پیش از انجام هر گونه عملیاتی در سمت سرور، نیاز است تا اصطلاحاً اقدام به Validation پارامترهای ارسالی کنیم. در این ارتباط، می‌باید قوانین سخت‌گیرانه‌ای برای پارامترهای ورودی در نظر بگیریم و چنانچه ریکوئستی نتوانست از سَد این اعتبارسنجی عبور کند، می‌باید جلوی انجام تَسک مربوطه را گرفته و پیام‌های خطای مرتبطی در قالب ریسپانس در اختیار کاربر بگذاریم.
