API Tester

A single-file WordPress plugin that adds a front-end shortcode for testing external APIs from inside a logged-in user's browser session, without ever storing the test requests themselves.

What it does

Add [api_tester_widget] to any page or post and logged-in users get a self-contained widget that can:

• Build and send an HTTP request (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) to any external URL
• Add custom request headers and typed fields (string, number, boolean, array, object, null) — fields become query parameters for GET/DELETE/HEAD/OPTIONS and a JSON body for POST/PUT/PATCH
• Save and reuse named authentication header profiles (e.g. Authorization: Bearer …) per user, so API keys don't need to be re-entered for every test
• View the response status, headers, and body (JSON is pretty-printed), with sensitive header values masked in the UI

Requests are made server-side via wp_remote_request() and are never logged or persisted — only the named auth header profiles are saved (in that user's wp_usermeta), so they can be reused across sessions.

How it works

• Registers the [api_tester_widget] shortcode plus four wp_ajax_* actions (api_tester_run_request, api_tester_save_auth_method, api_tester_delete_auth_method, api_tester_get_auth_methods), all gated on is_user_logged_in() and a nonce (check_ajax_referer)
• Requests are capped at a 30-second timeout and responses truncated to 200KB
• Basic SSRF guardrails: the target host is resolved and checked against localhost, loopback, link-local/metadata (169.254.169.254), and private/reserved IP ranges before the request is made
• Sensitive-looking header names (Authorization, X-API-Key, Token, etc.) are masked in both the saved-method preview and the returned request-header echo

Installation

1. Copy api-tester-shortcode.php into wp-content/plugins/api-tester-shortcode/
2. Activate API Tester Shortcode from the WordPress admin Plugins screen
3. Add [api_tester_widget] to any page or post

Notes / caveats

• Any logged-in user (regardless of role) can use the widget — there's no additional capability check beyond being logged in. If your site allows open self-registration, consider restricting the shortcode to a page behind a role check, or adding a current_user_can() gate before exposing it site-wide.
• Saved auth headers are stored in plaintext in wp_usermeta. Treat them like any other credential store — a database leak exposes them.
• The SSRF protections validate the initial request URL and directly-resolved IP, but do not re-validate DNS on connection or re-check redirect targets. Don't treat this as a hardened proxy for untrusted or adversarial users — it's built for trusted, logged-in staff testing known APIs, not as a public-facing service.