CORS و اصول امنیت Web API

.NET 10 | Origin Policy، Input Security و Hardening

CORS سیاست مرورگر برای کنترل Requestهای Cross-Origin است و جای Authentication یا Authorization را نمی‌گیرد. امنیت API مجموعه‌ای از Transport Security، Validation، Least Privilege و مدیریت امن Secretهاست.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

CORS سیاست مرورگر برای کنترل Requestهای Cross-Origin است و جای Authentication یا Authorization را نمی‌گیرد. امنیت API مجموعه‌ای از Transport Security، Validation، Least Privilege و مدیریت امن Secretهاست.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

2. ساختار پیشنهادی در پروژه

Allowed Originها صریح تعریف می‌شوند. AllowAnyOrigin همراه Credential استفاده نمی‌شود. Middlewareهای امنیتی بر اساس محیط و مدل Authentication تنظیم می‌شوند.

builder.Services.AddCors(options =>
{
    options.AddPolicy("Frontend", policy =>
    {
        policy.WithOrigins("https://app.example.com")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

app.UseCors("Frontend");

3. سناریوی اجرایی

در API دارای JWT Bearer، CORS تنها تعیین می‌کند Browser از چه Originی اجازه ارسال Request دارد. مهاجم خارج از Browser همچنان می‌تواند Request بفرستد؛ بنابراین مجوز واقعی در Authentication/Authorization enforce می‌شود.

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

// Prefer parameterized LINQ / EF Core
var product = await db.Products
    .FirstOrDefaultAsync(p => p.Name == name, cancellationToken);

// Never concatenate untrusted input into raw SQL.

4. اصول طراحی و نگهداری

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

• HTTPS در Production اجباری باشد.
• CORS تا حد نیاز واقعی باز شود.
• Rate Limit و Upload Limit برای کنترل منابع اعمال شود.
• Security Headerها با Reverse Proxy و Hosting هماهنگ شوند.

5. خطاهای رایج و کنترل آن‌ها

بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص می‌شود. موارد زیر باید در بازبینی کد و تست‌های قبل از انتشار کنترل شوند.

• AllowAnyOrigin برای API دارای Credential مرورگر.
• فرض اینکه CORS یک Firewall سمت Server است.
• ساخت SQL خام با Concatenation ورودی.
• Log کردن Token، Password یا Connection String.

6. چک‌لیست نهایی فصل

• Originهای مجاز محدود و مشخص‌اند.
• HTTPS و HSTS متناسب با محیط تنظیم شده‌اند.
• ورودی‌ها Limit و Validation دارند.
• Endpoint حساس بدون Authorization باقی نمانده است.

7. جمع‌بندی

مفاهیم این فصل زمانی کامل محسوب می‌شوند که هم مسیر موفق و هم مسیر خطا قابل پیش‌بینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.