کدنویسی امن؛ چرا نباید هرگز به ورودی‌های کاربر اعتماد کرد؟

در دنیای توسعه نرم‌افزار، شکاف بزرگ میان یک «کدنویس» و یک «مهندس نرم‌افزار»، در نحوه برخورد با داده‌های ورودی است. امنیت یک سیستم، قبل از آنکه به فایروال‌ها وابسته باشد، به کیفیت کدهایی که می‌نویسیم بستگی دارد.

#### 🛡 اصل طلایی: Never Trust User Input
فرقی نمی‌کند شما یک فرم تماس ساده می‌سازید یا یک API پیچیده؛ هر داده‌ای که از سمت کاربر می‌آید (پارامترهای URL، بدنه درخواست‌های POST، یا حتی هدرها) می‌تواند سمی باشد.

#### ❌ رویکرد خطرناک (آسیب‌پذیر در برابر SQL Injection):
بسیاری از توسعه‌دهندگان مبتدی، ورودی کاربر را مستقیماً در کوئری‌های پایگاه داده قرار می‌دهند:

// بسیار خطرناک!
const userId = req.body.id;
const query = `SELECT * FROM users WHERE id = ${userId}`; 
db.execute(query);

*در این حالت، یک نفوذگر می‌تواند با وارد کردن مقداری مثل 1 OR 1=1 به تمام اطلاعات دیتابیس دسترسی پیدا کند.*

#### ✅ رویکرد حرفه‌ای (استفاده از Prepared Statements):
در سطح مهندسی، ما از پارامتریزه کردن کوئری‌ها استفاده می‌کنیم تا موتور پایگاه داده، ورودی را فقط به عنوان «داده» ببیند، نه بخشی از دستورات اجرایی:

// ایمن و حرفه‌ای
const userId = req.body.id;
const query = "SELECT * FROM users WHERE id = ?";
db.execute(query, [userId]); 

#### 🛠 سه گام برای افزایش امنیت در پروژه‌های وب:

1. Validation (اعتبارسنجی): چک کنید که آیا داده اصلاً فرمت درستی دارد؟ (مثلاً ایمیل واقعاً ایمیل است؟)
2. Sanitization (پاک‌سازی): حذف کاراکترهای خطرناک (مانند <script> یا کدهای SQL) از ورودی‌ها.
3. Principle of Least Privilege: اپلیکیشن شما باید با کمترین دسترسی ممکن به دیتابیس متصل شود. (مثلاً دسترسی حذف یا Drop کردن جداول را نداشته باشد).

#### 💡 نتیجه‌گیری برای توسعه‌دهندگان:
امنیت یک ویژگیِ الحاقی (Add-on) نیست که در پایان پروژه به آن فکر کنیم؛ امنیت باید در تار و پود کدهای ما تنیده شده باشد. با رعایت همین نکات ساده، جلوی بیش از ۸۰٪ حملات رایج وب گرفته می‌شود.

---
#برنامه_نویسی #امنیت_نرم_افزار #WebSecurity #SQLInjection #CleanCode #توسعه_وب #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی