WordPress is_admin() không phải kiểm tra quyền: dùng gì thay thế?

Một lỗi secure coding khá phổ biến trong plugin và theme WordPress là sử dụng is_admin() như thể hàm này trả lời câu hỏi:

“Người đang gửi request có phải Administrator không?”

Thực tế, is_admin() không kiểm tra role, capability hay quyền của người dùng.

Tài liệu chính thức của WordPress định nghĩa is_admin() là hàm xác định request hiện tại có đang thuộc administrative interface hay không. WordPress cũng ghi rõ hàm này không kiểm tra user có phải administrator và khuyến nghị dùng current_user_can() để kiểm tra capability.

Sự khác biệt tưởng nhỏ nhưng có thể trở thành security issue khi is_admin() được đặt trước những hành động nhạy cảm như upload file, thay đổi cấu hình, sửa dữ liệu hoặc xử lý request từ admin-post.php và admin-ajax.php.

Nguyên tắc cần nhớ là:

Admin context ≠ authentication ≠ authorization.

`is_admin()` thực sự kiểm tra điều gì?

Trong WordPress Core, is_admin() trả về true khi request được xác định đang chạy trong administrative interface.

Logic của Core về cơ bản dựa trên current screen hoặc hằng WP_ADMIN:

function is_admin() {
    if ( isset( $GLOBALS['current_screen'] ) ) {
        return $GLOBALS['current_screen']->in_admin();
    } elseif ( defined( 'WP_ADMIN' ) ) {
        return WP_ADMIN;
    }

    return false;
}

Điều cần chú ý là đoạn code này không kiểm tra current user, không kiểm tra role và cũng không gọi capability API.

Vì vậy đoạn code:

if ( is_admin() ) {
    // thực hiện hành động nhạy cảm
}

chỉ nói rằng:

Request đang ở một admin context.

Nó không chứng minh:

Người gửi request được phép thực hiện hành động đó.

`is_admin()` vẫn có mục đích hợp lệ

Điều này không có nghĩa developer không nên dùng is_admin().

Hàm này hữu ích để quyết định code nào chỉ cần chạy trong administration interface.

Ví dụ:

if ( is_admin() ) {
    add_action( 'admin_enqueue_scripts', 'my_admin_assets' );
}

Ở đây developer chỉ muốn tải resource trong khu vực quản trị.

Không có authorization decision nhạy cảm nào được đưa ra, nên is_admin() phù hợp.

Vấn đề xuất hiện khi hàm được biến thành security gate.

Authentication, authorization và admin context khác nhau thế nào?

Để code WordPress an toàn, nên tách ba khái niệm này thành ba câu hỏi độc lập.

Authentication: người gửi request là ai?

Authentication xác định identity.

Trong WordPress, đó có thể là:

logged-in user với authentication cookie;
REST API client dùng Application Password;
request không authenticated;
một integration sử dụng cơ chế xác thực khác.

Authentication chỉ chứng minh identity.

Một user đã đăng nhập chưa chắc được phép thực hiện mọi hành động.

Authorization: user đó được phép làm gì?

Authorization quyết định user có capability cần thiết đối với hành động hoặc object cụ thể hay không.

Trong WordPress, hàm thường dùng là:

current_user_can()

Ví dụ:

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized request.' );
}

WordPress mô tả current_user_can() là hàm kiểm tra current user có capability được chỉ định hay không. Với meta capability như edit_post, developer còn có thể truyền object ID để WordPress tính permission đối với chính object đó.

Admin context: request đang chạy ở đâu?

Đây mới là câu hỏi của:

is_admin()

Nó mô tả context, không phải quyền.

Có thể hình dung:

is_admin()
    ↓
Request có thuộc admin interface không?

current_user_can()
    ↓
Current user có được phép làm hành động này không?

Hai hàm giải quyết hai bài toán khác nhau.

Vì sao `/wp-admin/` không có nghĩa request đã được cấp quyền?

Một nguyên nhân khiến developer dễ dùng sai is_admin() là giả định tất cả URL dưới /wp-admin/ đều chỉ dành cho Administrator.

WordPress không hoạt động đơn giản như vậy.

Một số endpoint trong khu vực này được thiết kế để dispatch request từ frontend hoặc từ user không đăng nhập.

Hai ví dụ quan trọng là:

/wp-admin/admin-post.php
/wp-admin/admin-ajax.php

Do đó, nhìn thấy /wp-admin/ trong URL không đủ để suy ra authentication hoặc authorization.

`admin-post.php` có thể xử lý request chưa đăng nhập

WordPress cung cấp hook:

admin_post_{$action}

cho một số request authenticated.

Đồng thời Core cũng có:

admin_post_nopriv_{$action}

dành cho request không authenticated. Tài liệu WordPress mô tả trực tiếp admin_post_nopriv_{$action} là hook chạy cho non-authenticated admin post request của action tương ứng.

Ví dụ:

add_action(
    'admin_post_nopriv_submit_public_form',
    'handle_public_form'
);

Ở đây anonymous visitor được phép đi vào callback.

Điều này có thể hoàn toàn hợp lệ nếu endpoint thực sự cần public access.

Sai lầm là để callback thực hiện hành động privileged mà không có security model phù hợp.

`admin-ajax.php` cũng có public action

WordPress AJAX sử dụng pattern tương tự.

Một action đăng ký bằng:

wp_ajax_nopriv_{$action}

được thiết kế cho logged-out user.

Tài liệu chính thức mô tả đây là hook xử lý unauthenticated AJAX action khi is_user_logged_in() trả về false.

Do đó:

URL nằm trong /wp-admin/

không đồng nghĩa:

Request đến từ administrator

và càng không đồng nghĩa:

Request có quyền sửa file hoặc thay đổi cấu hình

Sai lầm nguy hiểm: dùng `is_admin()` làm authorization gate

Giả sử một plugin có code:

function update_plugin_file() {
    if ( ! is_admin() ) {
        return;
    }

    // xử lý file upload
}

Developer có thể nghĩ callback đã được bảo vệ vì chỉ chạy trong admin.

Nhưng điều kiện này chỉ kiểm tra context.

Nếu request đi qua một route tạo ra admin context nhưng không yêu cầu authentication tương ứng, security check có thể trở nên vô nghĩa.

Trường hợp CVE-2026-87935

SecureWebOps vừa phân tích một ví dụ thực tế trong bài CVE-2026-87935: Paid Downloads có lỗi upload file qua admin-post.php, có thể dẫn tới RCE.

Lỗ hổng liên quan một upload handler có vấn đề authorization và file-type validation.

Bài học rộng hơn không nằm ở riêng Paid Downloads.

Nó là lời nhắc rằng developer phải xác định security boundary bằng identity và capability, chứ không bằng tên URL hoặc request context.

Khi nào cần dùng `current_user_can()`?

Nếu hành động chỉ được phép cho một nhóm user có quyền cụ thể, capability check phải diễn ra trước khi state-changing operation được thực hiện.

Ví dụ plugin có chức năng thay đổi cấu hình:

function save_plugin_settings() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Unauthorized request.' );
    }

    // xử lý dữ liệu sau khi authorization đã PASS
}

Ở đây manage_options chỉ là ví dụ.

Capability đúng phải phụ thuộc chức năng nghiệp vụ.

Không nên kiểm tra role trực tiếp nếu có thể dùng capability

Code kiểu:

if ( in_array( 'administrator', $user->roles, true ) ) {
    // ...
}

thường kém linh hoạt hơn capability check.

WordPress cũng khuyến nghị kiểm tra capability thay vì dựa vào role cụ thể, vì custom role hoặc capability mapping có thể làm mô hình phân quyền khác với assumption của developer.

Ví dụ:

current_user_can( 'edit_posts' );

hoặc với object cụ thể:

current_user_can( 'edit_post', $post_id );

Object-level check đặc biệt quan trọng.

Một editor được phép sửa một số post không có nghĩa họ tự động được phép sửa mọi object trong mọi context.

Nếu cần thiết kế permission model tổng thể, SecureWebOps đã có bài riêng về WordPress Roles & Capabilities: thiết kế phân quyền và Access Review và Least Privilege WordPress.

Nonce có thay thế `current_user_can()` không?

Không.

Đây là lỗi thứ hai thường xuất hiện cạnh việc dùng sai is_admin().

Developer thêm một nonce rồi cho rằng endpoint đã được bảo vệ:

check_admin_referer( 'update_file' );

// thực hiện privileged action

Nonce có vai trò quan trọng, nhưng nonce không phải authorization.

Tài liệu WordPress nói rõ nonce không nên được dựa vào để làm authentication, authorization hoặc access control. WordPress khuyến nghị vẫn phải bảo vệ function bằng current_user_can().

Nonce giải quyết vấn đề gì?

Nonce chủ yếu giúp kiểm chứng rằng request có intent/token phù hợp và giảm rủi ro từ một số dạng CSRF.

Ví dụ attacker dụ một Administrator đang đăng nhập mở một trang độc hại.

Browser của nạn nhân có thể tự gửi cookie WordPress trong request tới site.

Nonce giúp endpoint phân biệt request được tạo từ workflow hợp lệ với một request giả mạo thiếu token cần thiết.

Nhưng nếu một user có nonce mà không có capability, user đó vẫn không nên được phép thực hiện privileged action.

Pattern an toàn hơn

Một state-changing handler authenticated thường cần cả hai:

function handle_sensitive_action() {

    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Unauthorized request.' );
    }

    check_admin_referer( 'sensitive_action' );

    // validate input
    // perform action
}

Hai control trả lời hai câu hỏi khác nhau:

current_user_can()
→ User có quyền làm việc này không?

check_admin_referer() / nonce
→ Request có mang token intent phù hợp không?

Thiếu một trong hai có thể tạo security gap khác nhau.

`check_ajax_referer()` có phải authorization không?

Cũng không.

Với AJAX, developer thường viết:

check_ajax_referer( 'my_action' );

Hàm này xác minh nonce của AJAX request.

Tài liệu WordPress tiếp tục nhấn mạnh rằng nonce không nên được dùng thay authentication, authorization hoặc access control; privileged AJAX callback vẫn cần capability check riêng.

Ví dụ:

add_action( 'wp_ajax_delete_private_record', 'delete_private_record' );

function delete_private_record() {

    check_ajax_referer( 'delete_private_record' );

    if ( ! current_user_can( 'delete_private_records' ) ) {
        wp_send_json_error(
            array( 'message' => 'Unauthorized' ),
            403
        );
    }

    // validate object ID
    // delete record
}

Ở đây nonce và capability bổ sung cho nhau.

Public endpoint thì có cần `current_user_can()` không?

Không phải mọi endpoint public đều phải gọi current_user_can().

Nếu business requirement thực sự cho phép anonymous user thực hiện hành động, capability của WordPress user có thể không phải security control phù hợp.

Ví dụ:

admin_post_nopriv_submit_contact_form

có thể cố ý nhận request public.

Nhưng public endpoint vẫn cần security design tương ứng.

Nó có thể cần:

input validation;
rate limiting;
anti-abuse control;
CSRF/session mechanism nếu workflow cần;
giới hạn hành động được phép;
safe file handling nếu có upload;
logging và monitoring.

Điểm quan trọng là developer phải chủ động quyết định endpoint là public, thay vì endpoint vô tình public vì assumption sai về /wp-admin/ hoặc is_admin().

File upload handler cần kiểm tra những lớp nào?

File upload là nơi lỗi authorization đặc biệt nguy hiểm vì một request sai quyền có thể biến thành file write.

Không có một hàm đơn lẻ nào đủ để bảo vệ toàn bộ upload workflow.

Một handler an toàn cần mô hình nhiều lớp:

Request
   ↓
Authentication
   ↓
Authorization
   ↓
Nonce / CSRF control khi phù hợp
   ↓
Input validation
   ↓
File validation
   ↓
Safe filename / destination
   ↓
Non-executable storage nếu có thể
   ↓
Logging / monitoring

Ví dụ, current_user_can() PASS không có nghĩa user được phép upload PHP.

Ngược lại, extension validation tốt không giải quyết lỗi một anonymous user đang truy cập chức năng đáng ra chỉ dành cho Administrator.

SecureWebOps đã có bài riêng về Bảo mật file upload WordPress: MIME, quyền upload và execution risk cho phần file validation và execution boundary.

5 anti-pattern nên tìm khi review plugin WordPress

Khi audit plugin hoặc custom code, các pattern sau đáng được review cùng nhau:

Dùng is_admin() trước một privileged action nhưng không có capability check.
Tin rằng URL /wp-admin/ tự động yêu cầu authentication.
Dùng nonce như permission check duy nhất.
Kiểm role cứng như administrator thay vì capability phù hợp.
Đăng ký admin_post_nopriv_* hoặc wp_ajax_nopriv_* cho callback có khả năng thay đổi state nhạy cảm mà không có security model rõ ràng.

Một pattern xuất hiện chưa tự động chứng minh vulnerability.

Code phải được đánh giá trong context thực tế: hook registration, authentication flow, data validation, capability model và action cuối cùng.

Mẫu handler authenticated an toàn hơn

Giả sử plugin cần cho phép user có capability riêng cập nhật một record:

add_action(
    'admin_post_update_secure_record',
    'update_secure_record'
);

function update_secure_record() {

    if ( ! current_user_can( 'edit_secure_records' ) ) {
        wp_die(
            'Unauthorized request.',
            'Forbidden',
            array( 'response' => 403 )
        );
    }

    check_admin_referer(
        'update_secure_record',
        'secure_record_nonce'
    );

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

    if ( ! $record_id ) {
        wp_die( 'Invalid record.' );
    }

    // Nếu permission phụ thuộc object,
    // kiểm tra capability trên object tại đây.

    // Validate dữ liệu còn lại.
    // Sau đó mới thực hiện state change.
}

Điểm đáng chú ý:

is_admin() hoàn toàn không cần thiết cho authorization ở đây.

Security decision dựa trên:

capability → nonce → input/object validation → state change

thay vì:

admin context → state change

Mẫu public handler nên được nghĩ khác

Nếu endpoint thực sự cần public:

add_action(
    'admin_post_nopriv_submit_public_request',
    'submit_public_request'
);

add_action(
    'admin_post_submit_public_request',
    'submit_public_request'
);

Developer không nên thêm một current_user_can() giả tạo nếu anonymous user là requirement.

Thay vào đó callback phải được thiết kế như một public attack surface.

Ví dụ, cần giới hạn input, kích thước request, file type nếu có upload, abuse frequency, dữ liệu được phép thay đổi và destination.

Một endpoint public không phải vulnerability chỉ vì nó public.

Vulnerability xuất hiện khi quyền thực tế của endpoint vượt quá quyền mà business logic muốn cấp cho anonymous caller.

Cách review code đang dùng `is_admin()`

Khi thấy:

is_admin()

trong plugin, không nên tự động đánh dấu là lỗi.

Thay vào đó hãy theo luồng code.

Checklist review ngắn:

is_admin() đang dùng để load UI/resource hay đang quyết định một privileged action?
Callback được gọi từ hook nào?
Hook có biến thể nopriv không?
Request yêu cầu authentication bằng cách nào?
Có current_user_can() phù hợp không?
Nếu thao tác trên object cụ thể, permission có gắn object ID không?
Nonce đang bảo vệ CSRF hay bị dùng nhầm như authorization?
Input có được validate trước khi state change?
Nếu có file write, destination có executable không?
Failure path có thật sự dừng xử lý hay code vẫn tiếp tục?

Điều quan trọng là review toàn bộ request-to-action path, không grep một hàm rồi kết luận.

Có nên thay mọi `is_admin()` bằng `current_user_can()`?

Không.

Hai hàm không phải phiên bản an toàn và không an toàn của cùng một chức năng.

Chúng giải quyết hai câu hỏi khác nhau.

Nếu code cần biết:

Có đang chạy trong admin interface không?

thì is_admin() vẫn đúng.

Nếu code cần biết:

User có quyền thực hiện thao tác này không?

thì dùng capability check.

Trong nhiều trường hợp cả hai có thể cùng xuất hiện:

if ( is_admin() ) {
    // chỉ đăng ký UI hoặc asset trong admin
}

if ( current_user_can( 'manage_options' ) ) {
    // quyết định user có quyền thực hiện action
}

Không nên thay thế máy móc.

Cần sửa security assumption.

`is_user_admin()` có kiểm tra Administrator không?

Tên hàm này cũng dễ gây hiểu nhầm.

is_user_admin() xác định request có thuộc user administration screen hay không, ví dụ khu vực /wp-admin/user/.

Tài liệu WordPress cũng ghi rõ hàm này không kiểm tra user có phải Administrator và tiếp tục khuyến nghị capability check cho roles/permissions.

Vì vậy các hàm có chữ “admin” trong tên không nên được diễn giải bằng tên tự nhiên của chúng.

Cần đọc semantics thực tế của API.

Khi nào lỗi này trở thành vulnerability nghiêm trọng?

Dùng sai is_admin() chỉ trở thành security vulnerability khi nó tạo ra một authorization gap có impact thực tế.

Mức độ nghiêm trọng phụ thuộc hành động nằm sau check.

Nếu callback chỉ hiển thị một admin notice, impact có thể không đáng kể.

Nếu callback cho phép:

upload hoặc ghi file;
cài plugin/theme;
thay đổi configuration;
tạo user;
sửa role/capability;
thay đổi password;
đọc secret;
cập nhật content của user khác;
thực hiện database operation nhạy cảm;

thì authorization bypass có thể dẫn đến hậu quả lớn hơn.

Do đó severity phải dựa trên reachable action + required access + resulting impact, không chỉ dựa vào sự tồn tại của is_admin().

Kết luận

is_admin() là một WordPress Conditional Tag dùng để xác định administrative interface context.

Nó không chứng minh user đã đăng nhập.

Nó không chứng minh user là Administrator.

Và nó không chứng minh user có capability thực hiện hành động hiện tại. Tài liệu chính thức của WordPress nói rõ muốn kiểm tra quyền nên sử dụng current_user_can().

Đối với secure WordPress development, nên giữ rõ bốn lớp:

Context
→ is_admin()

Authentication
→ user/session identity

Authorization
→ current_user_can()

Request integrity
→ nonce / check_admin_referer() / check_ajax_referer()

Sau đó mới tới input validation, file validation và state change.

Đặc biệt với admin-post.php và admin-ajax.php, đừng coi /wp-admin/ là security boundary: WordPress có các hook nopriv được thiết kế riêng cho unauthenticated request.

Nếu đang review plugin hoặc custom WordPress code, hãy kiểm tra authorization tại callback thực hiện hành động nhạy cảm, thay vì suy luận quyền từ URL hoặc is_admin().

Internal link đề xuất: bài CVE-2026-87935 → bài này ở anchor “is_admin() không phải kiểm tra quyền”; bài này → WordPress Roles & Capabilities, Least Privilege WordPress và Bảo mật File Upload WordPress.

is_admin() thực sự kiểm tra điều gì?

is_admin() vẫn có mục đích hợp lệ

Authentication, authorization và admin context khác nhau thế nào?

Authentication: người gửi request là ai?

Authorization: user đó được phép làm gì?

Admin context: request đang chạy ở đâu?

Vì sao /wp-admin/ không có nghĩa request đã được cấp quyền?

admin-post.php có thể xử lý request chưa đăng nhập

admin-ajax.php cũng có public action

Sai lầm nguy hiểm: dùng is_admin() làm authorization gate

Trường hợp CVE-2026-87935

Khi nào cần dùng current_user_can()?

Không nên kiểm tra role trực tiếp nếu có thể dùng capability

Nonce có thay thế current_user_can() không?

Nonce giải quyết vấn đề gì?

Pattern an toàn hơn

check_ajax_referer() có phải authorization không?

Public endpoint thì có cần current_user_can() không?

File upload handler cần kiểm tra những lớp nào?

5 anti-pattern nên tìm khi review plugin WordPress

Mẫu handler authenticated an toàn hơn

Mẫu public handler nên được nghĩ khác

Cách review code đang dùng is_admin()

Có nên thay mọi is_admin() bằng current_user_can()?

is_user_admin() có kiểm tra Administrator không?

Khi nào lỗi này trở thành vulnerability nghiêm trọng?

Kết luận

`is_admin()` thực sự kiểm tra điều gì?

`is_admin()` vẫn có mục đích hợp lệ

Vì sao `/wp-admin/` không có nghĩa request đã được cấp quyền?

`admin-post.php` có thể xử lý request chưa đăng nhập

`admin-ajax.php` cũng có public action

Sai lầm nguy hiểm: dùng `is_admin()` làm authorization gate

Khi nào cần dùng `current_user_can()`?

Nonce có thay thế `current_user_can()` không?

`check_ajax_referer()` có phải authorization không?

Public endpoint thì có cần `current_user_can()` không?

Cách review code đang dùng `is_admin()`

Có nên thay mọi `is_admin()` bằng `current_user_can()`?

`is_user_admin()` có kiểm tra Administrator không?