Trust Me, Claude, It’s My WordPress Route

Level 1: Show the Lock

Imagine someone pointing at a door and saying, “This house is definitely mine, and the door is definitely safe—right?” while wearing spy glasses and typing on a toy computer. You cannot judge the lock from the street name, and you cannot prove ownership because the stranger added “by the way.” That mismatch between huge hacker confidence and almost no evidence is why the picture is funny.

Level 2: A Path Is Not Armor

A REST API lets programs interact with a site through HTTP requests. WordPress commonly exposes this interface beneath wp-json. A route might read public posts, update an account, or run functionality added by a plugin. Simply being reachable is normal; what matters is whether each operation reveals or changes only what it should.

When reviewing an endpoint, ask:

1. Which HTTP methods does it accept—read, create, update, or delete?
2. How is the caller authenticated?
3. Does permission_callback check the exact capability and resource?
4. Are every path, query, and body parameter validated and sanitized?
5. Does the callback safely access the database and encode output?
6. Do tests include anonymous users, low-privilege users, malformed input, and attempts to access another user’s object?

The meme’s “amirite??” asks for reassurance rather than review. A useful AI assistant should ask for the route registration and callback code, state what it cannot verify, and recommend controlled testing. A confident yes based only on wp-json would be generated security theater—very polished, very fast, and approximately as protective as the plastic laptop.

Level 3: Trust-Me-Bro Authentication

yo claude, this wp-json route
which totally belongs to my site btw
is completely secure amirite??

The phrase “totally belongs to my site btw” is volunteered with exactly the confidence of someone who has not been asked for proof. Beneath it, a smirking operator in tiny pink sunglasses taps on a bright blue children’s laptop against Matrix-style code rain. The visual combines the aesthetics of an elite penetration tester with the equipment and assurance process of a school lunchbox. Claude is being asked for both a security verdict and, potentially, moral cover.

wp-json is normally the base path for the WordPress REST API. Its presence does not prove a vulnerability, and hiding or renaming the path does not make an unsafe endpoint secure. A route is an address; security comes from what the endpoint behind that address accepts, exposes, changes, and permits. Declaring a route “completely secure” from its path is like approving a bank vault after inspecting the street sign.

For a custom WordPress endpoint, the crucial boundary is its permission_callback. WordPress authenticates the request first, establishing the current user when credentials are valid, and then the permission callback should perform authorization: can this particular user perform this particular action on this particular object? Checking only “is somebody logged in?” is weaker than checking a relevant capability with current_user_can(...). A public endpoint can deliberately allow everyone, but that needs to be an explicit design decision, not the accidental result of a callback that returns the wrong false-like value.

Authentication and authorization solve different problems:

• Authentication establishes who sent the request.
• Authorization decides what that identity may do.
• A WordPress REST nonce helps protect cookie-authenticated requests against cross-site request forgery; it is not a substitute for a capability check and is not proof that the caller owns the site.
• Validation rejects inputs with the wrong shape or unacceptable values.
• Sanitization converts permitted input into a safer, canonical form before use.

A defensive route definition makes those decisions visible:

register_rest_route('acme/v1', '/posts/(?P<id>\d+)', [
    'methods'  => WP_REST_Server::EDITABLE,
    'callback' => 'acme_update_post',
    'permission_callback' => function (WP_REST_Request $request) {
        return current_user_can('edit_post', (int) $request['id']);
    },
    'args' => [
        'id' => [
            'validate_callback' => 'is_numeric',
            'sanitize_callback' => 'absint',
        ],
    ],
]);

Even that snippet is not a certificate of safety. The callback can still contain broken object-level access control, unsafe database queries, mass assignment, excessive data exposure, stored cross-site scripting, or destructive side effects on the wrong HTTP method. The review also needs the plugin and WordPress versions, endpoint implementation, authentication scheme, deployment configuration, data sensitivity, rate controls, error behavior, and a threat model. “Completely secure” is not a useful engineering state; it is what gets written immediately before the retrospective calendar invite.

The AI angle adds another trust problem. A model can explain patterns and review supplied code, but a conversational claim of ownership is not authorization to probe a target. Responsible active testing needs clear scope, permission from the system owner, limits on techniques, and care with production data. Without those, the assistant should remain in defensive analysis: inspect code the user is entitled to share, suggest local tests, and avoid turning a suspicious URL into an unsolicited security assessment.

The joke ultimately targets two kinds of wishful outsourcing. The user wants Claude to infer ownership from “btw” and infer security from a route name. Neither is evidence. Security comes from explicit controls and verification, while permission comes from explicit authority. The toy computer is almost beside the point; the real toy is the threat model.