从安全角度，通过自定义PHP API获取WordPress文章ID是否合理？

我开发了一个自定义WordPress PHP REST API，包含两个功能：一是返回网站所有文章，二是按slug返回文章。目前正在为该博客网站开发移动端应用，需要获取文章数据，其中包含文章ID。我对此存在顾虑，想从安全角度询问：通过该自定义PHP API获取WordPress文章ID是否合理？

另外还有一种方案：不使用该自定义API，而是将文章信息存入MySQL数据库，通过PHP API获取数据，但使用我自定义的文章ID（不采用WordPress自带的文章ID）。

请问从安全角度出发，哪种方案更优？

以下是我的自定义PHP API函数：

function api_posts()
{
    $args = [
        'numberposts' => 99999,
        'post_type' => 'post',
    ];

    $posts = get_posts($args);

    $data = [];
    $i = 0;

    foreach ($posts as $post) {
        $category = get_the_category( $post->ID )[0]->name;
        $data[$i]['category'] = $category;
        $data[$i]['id'] = $post->ID;
        $data[$i]['title'] = $post->post_title;
        $data[$i]['excerpt'] = $post->post_excerpt;
        $data[$i]['content'] = $post->post_content;
        $data[$i]['slug'] = $post->post_name;
       // $data[$i]['featured_image']['thumbnail'] = get_the_post_thumbnail_url($post->ID, 'thumbnail');
        $data[$i]['thumbnailImage'] = get_the_post_thumbnail_url($post->ID, 'thumbnail');
        $data[$i]['mediumImage'] = get_the_post_thumbnail_url($post->ID, 'medium');
        $data[$i]['largeImage'] = get_the_post_thumbnail_url($post->ID, 'large');
        setlocale(LC_TIME, array('tr_TR.UTF-8','tr_TR.UTF-8','tr_TR.UTF-8','tr_TR.UTF-8'));//tarihi esas alan locali seçer
        $gelen_date = $post->post_date;
        $data[$i]['date'] = strftime("%e %B %Y",strtotime($gelen_date));
        $data[$i]['post_url'] = get_permalink($post->ID);
        $i++;
    }

    return $data;
}

add_action('rest_api_init', function () {
    register_rest_route('api/v1', 'posts', [
        'methods' => 'GET',
        'callback' => 'api_posts',

    ]);

    register_rest_route('api/v1', 'posts/(?P<slug>[a-zA-Z0-9-]+)', array(
        'methods' => 'GET',
        'callback' => 'api_post',
    ));
});

注：网站尚未发布，测试阶段使用免费WordPress博客主题，正式发布时将使用Jannah主题。

方案安全分析与结论 #

1. 暴露WordPress原生文章ID的安全性 #

WordPress原生文章ID属于低敏感公开信息：

• 公开站点的文章ID本来就可通过前端页面、官方REST API（默认/wp-json/wp/v2/posts）获取，不属于保密内容；
• 单纯暴露ID不会直接引发安全风险，只要你的API仅提供读取操作（无写入/修改/删除逻辑），就不存在核心安全隐患；
• 你的API已支持按slug查询文章，避开了用ID作为查询参数，进一步降低了被恶意遍历的可能。

需注意的细节：

• 确保API只返回已发布的公开文章，当前代码用get_posts默认仅获取发布状态内容，这一点没问题；
• 避免在返回数据中泄露用户ID、后台路径等其他敏感信息。

2. 自定义ID+独立数据库存储方案的安全性 #

该方案看似更“隐蔽”，但实际安全收益极低，反而带来额外风险：

• 冗余维护成本：需要同步WordPress文章到独立数据库，一旦文章更新、删除，需保证数据一致性，否则会出现移动端与网站数据不同步的问题；
• 新增攻击面：自定义数据库连接和API代码，若未做好输入校验、参数过滤，可能引入SQL注入、权限控制漏洞，风险反而高于基于WordPress原生函数的API；
• 隐蔽性≠安全性：自定义ID只是隐藏了原生ID，但攻击者仍可通过slug或其他公开信息爬取全部文章内容，本质无法阻止合法信息的正常访问。

3. 最优方案选择 #

优先选择保留原生WordPress ID的自定义API方案，理由：

• 复用WordPress原生get_posts、get_permalink等成熟函数，避免重复造轮子，减少代码漏洞；
• 原生ID更贴合WordPress生态，后续扩展关联评论、分类等功能更便捷；
• 只要做好基础安全配置，暴露ID不会带来实质性安全问题。

额外优化建议 #

• 限制numberposts取值：当前设为99999，文章过多时会导致API响应缓慢甚至崩溃，建议改成分页查询（通过paged参数实现）；
• 添加API权限控制：即使是公开文章，可通过permission_callback限制请求来源，或添加请求频率限制，防止恶意爬取；
• 精简返回字段：只返回移动端需要的数据，避免冗余内容；
• 考虑官方REST API替代：WordPress自带的API已支持按slug查询文章（/wp-json/wp/v2/posts?slug=xxx），若需求不复杂，直接使用官方API可减少自定义代码的维护成本。

内容的提问来源于stack exchange，提问作者mesh