اصول امنیت در برنامه‌نویسی وردپرس — راهنمای کامل توسعه دهندگان

وقتی صحبت از امنیت وردپرس می‌شود، اولین چیزی که به ذهن اکثر افراد می‌رسد نصب یک افزونه امنیتی است. اما حقیقت تلخ اینجاست که بسیاری از حملات موفق، نه از ضعف هسته وردپرس، بلکه از کدی که خودِ توسعه‌دهنده نوشته یا همان افزونه امنیتی آپدیت نشده انجام می‌شوند.

یک تابع کوچک که ورودی کاربر را بدون پاک‌سازی در دیتابیس ذخیره می‌کند، می‌تواند کل سایت را در معرض خطر قرار دهد. به همین دلیل، امنیت پیش از آنکه یک افزونه باشد، یک سبک کدنویسی است.

در این مقاله کاربردی از هپتا، هفت اصل بنیادی امنیت در برنامه‌نویسی وردپرس را با مثال بررسی می‌کنیم؛ اصولی که هر توسعه‌دهنده و طراح سایت باید آن‌ها را به عادت روزمره خود تبدیل کند.

چرا امنیت در مرحله کدنویسی اهمیت دارد؟

افزونه‌های امنیتی مثل دیوار دور خانه عمل می‌کنند؛ مفید هستند، اما اگر درِ خانه را باز بگذارید، هیچ دیواری نجاتتان نمی‌دهد. کد ناامن دقیقاً همان درِ باز است.

بسیاری از آسیب‌پذیری‌های شناخته‌شده در افزونه‌ها و قالب‌ها، ریشه در خطاهای ساده کدنویسی دارند: عدم اعتبارسنجی ورودی، فراموش کردن escape خروجی، یا اعتماد بی‌جا به داده‌های کاربر.

تفاوت امنیت سطحی و امنیت ساختاری

امنیت سطحی یعنی اقداماتی که از بیرون به سایت اضافه می‌کنید: فایروال، تغییر آدرس صفحه ورود، محدودسازی تلاش برای لاگین. این موارد لازم‌اند اما کافی نیستند.

امنیت ساختاری یعنی امنیتی که در خودِ کد تنیده شده است. وقتی هر ورودی را پاک (Sanitize) و هر خروجی را escape می‌کنید، حتی اگر لایه‌های بیرونی شکست بخورند، مهاجم سرش به سنگ میخورد.

اصل اول — اعتبارسنجی و پاک‌سازی داده‌های ورودی

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

Validate vs Sanitize — تفاوت کجاست؟

این دو مفهوم اغلب با هم اشتباه گرفته می‌شوند، در حالی که نقش متفاوتی دارند:

• Validation (اعتبارسنجی): بررسی می‌کند که داده درست و مجاز است یا نه. مثلاً آیا این رشته (String) واقعاً یک ایمیل معتبر است؟ اگر نبود، داده را رد می‌کنیم.
• Sanitization (پاک‌سازی): داده را تمیز و بی‌خطر می‌کند؛ کاراکترها یا تگ‌های ناخواسته را حذف یا اصلاح می‌کند تا ذخیره آن امن باشد.

همین الان جلوی مانیتور روی استیک نوت بنویس: ورودی‌ها را هنگام دریافت validate و sanitize کنید، و خروجی‌ها را هنگام نمایش escape کنید.

توابع کاربردی وردپرس برای sanitization

وردپرس مجموعه‌ای از توابع آماده برای پاک‌سازی انواع داده در اختیار شما می‌گذارد:

• sanitize_text_field() — برای فیلدهای متنی ساده
• sanitize_email() — برای آدرس ایمیل
• sanitize_textarea_field() — برای متن چندخطی
• absint() — برای تبدیل به عدد صحیح مثبت
• sanitize_key() — برای کلیدها و اسلاگ‌ها
• wp_kses_post() — برای متنی که باید HTML مجاز را نگه دارد

// دریافت و پاک‌سازی امن داده‌های فرم
$name  = isset( $_POST['name'] )
    ? sanitize_text_field( wp_unslash( $_POST['name'] ) )
    : '';

$email = isset( $_POST['email'] )
    ? sanitize_email( wp_unslash( $_POST['email'] ) )
    : '';

$age   = isset( $_POST['age'] )
    ? absint( $_POST['age'] )
    : 0;

// اعتبارسنجی پس از پاک‌سازی
if ( ! is_email( $email ) ) {
    wp_die( 'ایمیل واردشده معتبر نیست.' );
}

دقت کنید که از wp_unslash() برای حذف بک‌اسلش‌هایی که وردپرس به‌صورت خودکار اضافه می‌کند استفاده کرده‌ایم.

اصل دوم — Escaping خروجی‌ها

اصل اول مربوط به «ورود امن داده» بود، اصل دوم درباره «خروج امن داده» است. حتی داده‌ای که فکر می‌کنید تمیز است، باید پیش از نمایش escape شود.

چرا escape کردن خروجی حیاتی است؟

حملات XSS (Cross-Site Scripting) زمانی رخ می‌دهند که داده‌ای حاوی کد جاوااسکریپت بدون escape در صفحه چاپ شود. مهاجم می‌تواند با این روش کوکی‌ها را بدزدد یا کاربر را به سایت مخرب هدایت کند.

قاعده ساده است: escape را تا لحظه نمایش به تأخیر بیندازید و دقیقاً متناسب با محل خروجی انجام دهید.

توابع esc_* در وردپرس

• esc_html() — برای نمایش متن داخل HTML
• esc_attr() — برای مقادیر داخل صفات (attribute)
• esc_url() — برای آدرس‌ها در href و src
• esc_js() — برای داده داخل کد جاوااسکریپت
• wp_kses_post() — برای خروجی HTML کنترل‌شده

// نمایش امن داده در خروجی
<h2><?php echo esc_html( $title ); ?></h2>

<a href="<?php echo esc_url( $link ); ?>"
   title="<?php echo esc_attr( $tooltip ); ?>">
    <?php echo esc_html( $anchor ); ?>
</a>

<input type="text"
   value="<?php echo esc_attr( $user_value ); ?>" />

نکته مهم: هر تابع escape را در محل درستش به کار ببرید. استفاده از esc_html() داخل یک صفت (Attribute)، یا esc_attr() برای یک URL، محافظت کاملی ایجاد نمی‌کند.

اصل سوم — جلوگیری از SQL Injection با $wpdb

SQL Injection یکی از خطرناک‌ترین و قدیمی‌ترین حملات وب است. زمانی رخ می‌دهد که ورودی کاربر مستقیماً وارد یک کوئری دیتابیس شود و مهاجم بتواند ساختار کوئری را دستکاری کند.

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

استفاده صحیح از prepare()

کلاس $wpdb متد prepare() را دارد که ورودی‌ها را به‌صورت امن داخل کوئری جای می‌دهد. این متد از placeholder استفاده می‌کند و داده را پیش از اجرا escape می‌کند.

global $wpdb;

// ❌ کد ناامن — هرگز این کار را نکنید
$user_id = $_GET['id'];
$result  = $wpdb->get_results(
    "SELECT * FROM {$wpdb->users} WHERE ID = $user_id"
);

// ✅ کد امن — با prepare و placeholder
$user_id = absint( $_GET['id'] );
$result  = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users} WHERE ID = %d",
        $user_id
    )
);

در نسخه امن، %d یعنی «اینجا یک عدد صحیح قرار می‌گیرد». placeholderهای رایج عبارت‌اند از:

• %d — برای عدد صحیح
• %f — برای عدد اعشاری
• %s — برای رشته

قانون ساده: هر متغیری که وارد کوئری می‌شود باید از طریق placeholder عبور کند، نه با الحاق مستقیم رشته.

اصل چهارم — احراز هویت و کنترل دسترسی

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

بررسی Capability و Role

وردپرس به‌جای بررسی نقش (Role) خام، استفاده از قابلیت (Capability) را توصیه می‌کند. این روش انعطاف‌پذیرتر و دقیق‌تر است.

// بررسی دسترسی پیش از انجام عملیات حساس
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'شما اجازه دسترسی به این بخش را ندارید.' );
}

// حالا با اطمینان ادامه می‌دهیم
update_option( 'my_plugin_setting', $value );

از بررسی مستقیم نقش مثل if ( $user->role === 'administrator' ) پرهیز کنید؛ Capability روش استانداردتر و امن‌تری است.

استفاده از Nonce برای فرم‌ها و AJAX

Nonce (مخفف Number used once) توکنی است که وردپرس برای جلوگیری از حملات CSRF تولید می‌کند. این حمله زمانی رخ می‌دهد که مهاجم کاربر را فریب می‌دهد تا ناخواسته یک درخواست را اجرا کند.

Nonce تضمین می‌کند که درخواست واقعاً از سایت شما و از سوی کاربر آگاه ارسال شده است.

// تولید nonce در فرم
 <form method="post">
    <?php wp_nonce_field( 'save_profile_action', 'profile_nonce' ); ?>
    <input type="text" name="display_name" />
    <button type="submit">ذخیره</button>;
</form>

// بررسی nonce هنگام پردازش فرم
if ( ! isset( $_POST['profile_nonce'] ) ||
     ! wp_verify_nonce(
         wp_unslash( $_POST['profile_nonce'] ),
         'save_profile_action'
     )
) {
    wp_die( 'درخواست نامعتبر است.' );
}

توجه داشته باشید که Nonce جایگزین بررسی Capability نیست. این دو مکمل یکدیگرند: Nonce می‌گوید «درخواست معتبر است» و Capability می‌گوید «کاربر مجاز است».

اصل پنجم — امنیت AJAX و REST API

درخواست‌های AJAX و REST API دروازه‌های ورودی داینامیک سایت شما هستند. اگر بدون محافظت رها شوند، به نقطه ضعف بزرگی تبدیل می‌شوند.

تفاوت wp_ajax_ و wp_ajax_nopriv_

وردپرس دو هوک برای مدیریت درخواست‌های AJAX دارد و درک تفاوت آن‌ها حیاتی است:

• wp_ajax_{action} — فقط برای کاربران وارد شده (logged-in)
• wp_ajax_nopriv_{action} — برای کاربران مهمان (logged-out)

// فقط کاربران وارد شده
add_action( 'wp_ajax_save_data', 'my_save_data_handler' );

function my_save_data_handler() {
    // بررسی nonce
    check_ajax_referer( 'my_ajax_nonce', 'security' );

    // بررسی دسترسی
    if ( ! current_user_can( 'edit_posts' ) ) {
        wp_send_json_error( 'دسترسی غیرمجاز', 403 );
    }

    $data = sanitize_text_field( wp_unslash( $_POST['data'] ) );
    // پردازش امن داده...

    wp_send_json_success( 'با موفقیت ذخیره شد.' );
}

یک اشتباه رایج این است که توسعه‌دهنده هوک nopriv_ را برای عملیات حساس فعال می‌کند و در عمل، در را برای کاربران ناشناس باز می‌گذارد. این هوک را فقط زمانی اضافه کنید که واقعاً به دسترسی مهمان نیاز دارید.

احراز هویت در REST API

هنگام ثبت endpoint سفارشی در REST API، آرگومان permission_callback اجباری است. هرگز آن را روی __return_true بدون دلیل قرار ندهید.

register_rest_route( 'myplugin/v1', '/settings', array(
    'methods'             => 'POST',
    'callback'            => 'my_update_settings',
    'permission_callback' => function () {
        return current_user_can( 'manage_options' );
    },
) );

این callback پیش از اجرای منطق اصلی بررسی می‌شود و خط دفاعی اول endpoint شماست.

اصل ششم — مدیریت فایل‌ها و آپلود امن

امکان آپلود فایل یکی از حساس‌ترین بخش‌های هر سایت است. اگر کنترل نشود، مهاجم می‌تواند فایل مخرب (مثلاً یک اسکریپت PHP) آپلود و آن را اجرا کند و کنترل کامل سرور را به دست بگیرد.

محدود کردن نوع فایل

هرگز به نام یا پسوند فایلی که کاربر ادعا می‌کند اعتماد نکنید. وردپرس تابع wp_check_filetype_and_ext() را برای بررسی واقعی نوع فایل ارائه می‌دهد.

// تعریف نوع فایل‌های مجاز
$allowed_types = array(
    'jpg|jpeg' => 'image/jpeg',
    'png'      => 'image/png',
    'pdf'      => 'application/pdf',
);

$filetype = wp_check_filetype_and_ext(
    $file['tmp_name'],
    $file['name'],
    $allowed_types
);

if ( ! $filetype['ext'] || ! $filetype['type'] ) {
    wp_die( 'این نوع فایل مجاز نیست.' );
}

برای آپلودهای استاندارد، بهترین کار استفاده از تابع داخلی wp_handle_upload() است که بسیاری از این بررسی‌ها را به‌صورت خودکار انجام می‌دهد.

جلوگیری از اجرای فایل در پوشه آپلود

حتی با محدودسازی نوع فایل، بهتر است یک لایه دفاعی دیگر اضافه کنید: جلوگیری از اجرای اسکریپت‌ها در پوشه uploads. این کار با یک فایل .htaccess (در سرور Apache) انجام می‌شود.

# در فایل wp-content/uploads/.htaccess
<Files *.php>
    deny from all
</Files>

این قانون اجرای هر فایل PHP در پوشه آپلود را مسدود می‌کند، حتی اگر مهاجم موفق به آپلود آن شود.

اصل هفتم — اشتباهات رایج که امنیت را به خطر می‌اندازند

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

• اعتماد به ورودی کاربر بدون اعتبارسنجی و پاک‌سازی
• فراموش کردن escape خروجی پیش از نمایش در صفحه
• الحاق مستقیم متغیر به کوئری SQL به‌جای استفاده از prepare()
• نمایش جزئیات خطا (WP_DEBUG فعال) در محیط Product سایت
• قرار دادن اطلاعات حساس مثل کلید API به‌صورت hardcode در کد
• استفاده از permission_callback با مقدار __return_true
• فعال کردن هوک nopriv_ برای عملیات حساس
• نادیده گرفتن به‌روزرسانی افزونه‌ها و قالب‌های وابسته

چک‌لیست نهایی امنیت برای توسعه‌دهندگان وردپرس

پیش از انتشار هر افزونه یا قالب، این چک‌لیست را مرور کنید:

• ✅ تمام ورودی‌ها با تابع مناسب sanitize_* پاک‌سازی شده‌اند
• ✅ تمام خروجی‌ها با تابع مناسب esc_* امن شده‌اند
• ✅ تمام کوئری‌های دیتابیس از $wpdb->prepare() استفاده می‌کنند
• ✅ عملیات حساس با current_user_can() محافظت شده‌اند
• ✅ فرم‌ها و درخواست‌های AJAX دارای Nonce معتبر هستند
• ✅ endpointهای REST API دارای permission_callback صحیح هستند
• ✅ آپلود فایل‌ها از نظر نوع و پسوند کنترل می‌شود
• ✅ هیچ اطلاعات حساسی به‌صورت hardcode در کد وجود ندارد

سوالات متداول (FAQ)

تفاوت sanitize و validate در وردپرس چیست؟

Validation بررسی می‌کند که داده درست و در قالب مجاز است (مثلاً آیا واقعاً یک ایمیل معتبر است). Sanitization داده را تمیز و بی‌خطر می‌کند و کاراکترهای ناخواسته را حذف می‌کند. در عمل اغلب هر دو را با هم به کار می‌برید.

Nonce در وردپرس چیست و چطور استفاده می‌شود؟

Nonce توکنی موقت است که از حملات CSRF جلوگیری می‌کند. با wp_nonce_field() آن را در فرم تولید و با wp_verify_nonce() یا check_ajax_referer() هنگام پردازش بررسی می‌کنید.

چطور از SQL Injection در وردپرس جلوگیری کنیم؟

همیشه از $wpdb->prepare() همراه با placeholder (مثل %d و %s) استفاده کنید و هرگز متغیر را مستقیماً به رشته کوئری الحاق نکنید.

آیا استفاده از افزونه امنیتی کافی است؟

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

بهترین روش برای امن‌سازی AJAX در وردپرس چیست؟

سه لایه را با هم رعایت کنید: بررسی Nonce با check_ajax_referer()، بررسی دسترسی با current_user_can()، و پاک‌سازی همه ورودی‌ها با توابع sanitize_*.

سخن آخر

امنیت در وردپرس پیش از آنکه یک افزونه باشد، یک سبک کدنویسی است. هفت اصلی که بررسی کردیم — پاک‌سازی ورودی، escape خروجی، prepare برای دیتابیس، کنترل دسترسی، Nonce، امنیت AJAX/REST و مدیریت امن فایل — پایه‌ای‌ترین لایه دفاعی هر پروژه وردپرسی را می‌سازند.

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

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