{"id":934,"date":"2026-09-25T17:46:15","date_gmt":"2026-09-25T17:46:15","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=934"},"modified":"2026-09-25T09:30:50","modified_gmt":"2026-09-25T09:30:50","slug":"what-is-captcha-how-bot-protection-works","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/what-is-captcha-how-bot-protection-works\/","title":{"rendered":"What Is CAPTCHA? How Bot Protection Works"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; CAPTCHA and Bot Protection<\/p>\n<p>CAPTCHA can make automated abuse more expensive, but it is not a complete security boundary. Your application still needs server-side checks, rate limits, accessible fallbacks, and useful monitoring.<\/p>\n<ul>\n<li><strong>Verify server-side<\/strong> \u2014 Never trust a browser token until your application verifies it with the provider.<\/li>\n<li><strong>Use layered controls<\/strong> \u2014 Combine CAPTCHA with rate limits, request validation, account controls, and monitoring.<\/li>\n<li><strong>Protect tokens<\/strong> \u2014 Keep secrets on the server and avoid logging complete tokens or other sensitive values.<\/li>\n<li><strong>Test accessibility<\/strong> \u2014 Check keyboard, screen-reader, mobile, narrow-display, and low-bandwidth paths before release.<\/li>\n<li><strong>Review privacy<\/strong> \u2014 Understand which browser, network, cookie, and interaction signals the provider processes.<\/li>\n<li><strong>Test failures<\/strong> \u2014 Check missing, invalid, expired, reused, wrong-site, and timeout scenarios instead of testing only the happy path.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">CAPTCHA is a risk and verification layer that estimates whether a request came from a human or an automated client. Modern systems rarely rely on a puzzle alone; they combine browser, session, timing, and interaction signals, then work best beside rate limiting and server-side validation.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 13 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#why-does-a-login-form-need-captcha\">Why does a login form need CAPTCHA?<\/a><\/li>\n<li><a href=\"#what-captcha-actually-does\">What CAPTCHA actually does<\/a><\/li>\n<li><a href=\"#different-captcha-approaches\">Different CAPTCHA approaches<\/a><\/li>\n<li><a href=\"#captcha-cannot-replace-rate-limiting\">CAPTCHA cannot replace rate limiting<\/a><\/li>\n<li><a href=\"#verify-the-token-on-your-server\">Verify the token on your server<\/a><\/li>\n<li><a href=\"#when-captcha-gets-in-the-users-way\">When CAPTCHA gets in the user&#039;s way<\/a><\/li>\n<li><a href=\"#privacy-starts-with-the-verification-request\">Privacy starts with the verification request<\/a><\/li>\n<li><a href=\"#wordpress-and-nginx-need-endpoint-coverage\">WordPress and Nginx need endpoint coverage<\/a><\/li>\n<li><a href=\"#test-the-failure-paths-not-only-the-checkbox\">Test the failure paths, not only the checkbox<\/a><\/li>\n<li><a href=\"#mistakes-i-still-look-for-during-review\">Mistakes I still look for during review<\/a><\/li>\n<li><a href=\"#check-these-before-enabling-captcha\">Check These Before Enabling CAPTCHA<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"why-does-a-login-form-need-captcha\">Why does a login form need CAPTCHA?<\/h2>\n<p>At 3 a.m., a login endpoint does not care whether the request came from a tired developer, a search crawler, or a bot trying thousands of passwords. They all arrive over HTTP. CAPTCHA adds another signal to that decision: is this interaction likely to be human, or should the request face another check?<\/p>\n<p>CAPTCHA stands for &#8220;Completely Automated Public Turing test to tell Computers and Humans Apart.&#8221; The old versions asked people to read distorted letters. Modern systems may combine browser signals, session history, interaction patterns, and a risk score instead.<\/p>\n<p>That does not make CAPTCHA a complete security boundary. I treat it as one control beside rate limiting, session security, authentication, and server-side validation.<\/p>\n<h2 id=\"what-captcha-actually-does\">What CAPTCHA actually does<\/h2>\n<p>CAPTCHA estimates whether the party performing an action is likely to be human. Depending on the provider, the user may see a task, a checkbox, or nothing at all unless the session looks risky.<\/p>\n<p>The purpose is not to prove human identity with mathematical certainty. The practical goal is to make unwanted automation more expensive without adding a puzzle to every legitimate request.<\/p>\n<h3>From browser request to server decision<\/h3>\n<ol>\n<li>The user opens a form or starts an action.<\/li>\n<li>The provider&#8217;s script or widget loads.<\/li>\n<li>The browser sends interaction and environment signals to the provider.<\/li>\n<li>The provider returns a token, response, or risk assessment.<\/li>\n<li>Your application sends that value to the provider&#8217;s verification endpoint with a server-side secret.<\/li>\n<li>Your application checks the result, hostname or site, action, score, expiry, and provider-specific error fields.<\/li>\n<li>The protected action runs only after server-side verification succeeds.<\/li>\n<\/ol>\n<p>A token arriving from the browser is untrusted input. JavaScript can be changed, requests can be replayed, and a visible widget can be copied into a fake page.<\/p>\n<p>I made a smaller version of this mistake while testing a form years ago. I checked that the widget appeared, but I did not check that the backend rejected a missing token. The page looked protected; the endpoint was not. A browser test is useful. It is not a security test.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>A browser token is untrusted input until your application verifies it with the provider. Keep the secret key server-side and do not perform the protected action before that check succeeds.<\/p>\n<\/div>\n<h2 id=\"different-captcha-approaches\">Different CAPTCHA approaches<\/h2>\n<p>CAPTCHA does not provide one fixed user experience. I look at accessibility, mobile behavior, privacy requirements, false positives, and support work before I look at the challenge itself.<\/p>\n<table>\n<thead>\n<tr>\n<th>Type<\/th>\n<th>How it works<\/th>\n<th>Useful when<\/th>\n<th>Limitations<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Text or image<\/td>\n<td>The user reads characters or selects objects.<\/td>\n<td>You need a visible, familiar challenge.<\/td>\n<td>It can create vision, language, and mobile-use problems.<\/td>\n<\/tr>\n<tr>\n<td>Checkbox<\/td>\n<td>The user checks a box while risk analysis runs in the background.<\/td>\n<td>You want a simple interaction for ordinary sessions.<\/td>\n<td>Risky sessions may still receive another challenge.<\/td>\n<\/tr>\n<tr>\n<td>Invisible risk analysis<\/td>\n<td>The provider evaluates request and interaction signals.<\/td>\n<td>You want most users to see no extra task.<\/td>\n<td>False positives can be difficult to explain.<\/td>\n<\/tr>\n<tr>\n<td>Behavior-based<\/td>\n<td>Timing, keyboard, pointer, and session context are evaluated.<\/td>\n<td>You need another signal against simple scripts.<\/td>\n<td>Privacy and accessibility need careful treatment.<\/td>\n<\/tr>\n<tr>\n<td>Alternative verification<\/td>\n<td>Email, WebAuthn, or another step verifies the user.<\/td>\n<td>A visual challenge is unsuitable for the workflow.<\/td>\n<td>It may require an account or another communication channel.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The &#8220;I&#8217;m not a robot&#8221; checkbox is often only the visible part. The real decision may include an IP address, cookies, session data, request rate, browser signals, and previous failures. The exact inputs differ by provider, so read its data-processing and retention terms instead of guessing.<\/p>\n<h2 id=\"captcha-cannot-replace-rate-limiting\">CAPTCHA cannot replace rate limiting<\/h2>\n<p>No. A bot may fail every challenge and still send enough traffic to keep Nginx workers busy, exhaust a database connection pool, or trigger expensive password-reset work. If your application performs that work before checking the request, CAPTCHA arrived too late.<\/p>\n<p>I put rate limiting before the application boundary whenever I can. It gives the upstream service less traffic to process and keeps a verification outage from becoming a resource-exhaustion problem.<\/p>\n<h3>Controls that belong together<\/h3>\n<ul>\n<li><strong>Rate limiting:<\/strong> Set limits by IP, account, API key, or another trustworthy identity.<\/li>\n<li><strong>Account controls:<\/strong> Limit failed logins and use progressive delays instead of relying only on permanent lockouts.<\/li>\n<li><strong>Request validation:<\/strong> Check CSRF tokens, the expected Origin where appropriate, and acceptable Content-Type values.<\/li>\n<li><strong>Server-side validation:<\/strong> Check field types, lengths, and allowed values in the application.<\/li>\n<li><strong>Network controls:<\/strong> Apply clearly defined rules at a reverse proxy, WAF, or CDN.<\/li>\n<li><strong>Monitoring:<\/strong> Watch verification failures, 4xx responses, request volume, and upstream latency together.<\/li>\n<\/ul>\n<p>An API repeatedly returning <code>429 Too Many Requests<\/code> is not automatically fixed by adding CAPTCHA. RFC 6585 defines status 429 for rate limiting and describes the <code>Retry-After<\/code> response field. For a practical look at limits and retry behavior, see <strong><a href=\"https:\/\/www.vps.tc\/blog\/en\/too-many-requests-meaning-fix-error-429\/\">What Does Too Many Requests Mean? Fix Error 429<\/a><\/strong>.<\/p>\n<p><strong>My rule:<\/strong> apply rate and request-size limits before CAPTCHA and before expensive application work.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>A 429 response controls request pressure, while CAPTCHA helps assess automation. Use both when an endpoint is expensive or attractive to bots.<\/p>\n<\/div>\n<h2 id=\"verify-the-token-on-your-server\">Verify the token on your server<\/h2>\n<p>The provider changes, but the security boundary stays in the same place. The browser submits a token to your application. Your application sends that token to the provider with a private secret. Only then should it authorize registration, login, or another protected operation.<\/p>\n<pre><code>POST \/api\/register HTTP\/1.1\nContent-Type: application\/json\n\n{\n  \"email\": \"user@example.net\",\n  \"password\": \"...\",\n  \"captcha_token\": \"token-sent-by-the-browser\"\n}<\/code><\/pre>\n<p>The following example shows the shape of a provider verification request, not a universal API. Use the selected provider&#8217;s documentation for the actual endpoint, field names, and response schema.<\/p>\n<pre><code>curl --fail-with-body --silent \\\n  -X POST \"https:\/\/captcha-provider.example\/verify\" \\\n  -d \"secret=${CAPTCHA_SECRET}\" \\\n  --data-urlencode \"response=${CAPTCHA_TOKEN}\"<\/code><\/pre>\n<p><code>--fail-with-body<\/code> preserves the response body while returning a failure status for an HTTP error. <code>--data-urlencode<\/code> is useful when a token contains characters that need encoding. Store the secret in an environment variable or secret manager, not in HTML, JavaScript, shell history, or Git.<\/p>\n<h3>Fields I check<\/h3>\n<ul>\n<li>Did verification succeed?<\/li>\n<li>Was the token created for the configured site or hostname?<\/li>\n<li>Does it match the action being performed?<\/li>\n<li>Does the score meet the threshold chosen for this workflow?<\/li>\n<li>Has it expired or already been accepted?<\/li>\n<li>Did the verification request time out or return an error?<\/li>\n<\/ul>\n<p>Token lifetime and replay behavior depend on the provider. Where the provider documents single-use tokens, reject a second use. I also keep an application-side record of accepted token identifiers or request nonces when the integration makes that practical.<\/p>\n<p>Decide what happens when the provider is unavailable. Queueing a newsletter subscription may be acceptable. Allowing an administrator login or money transfer to continue without verification is a different risk decision.<\/p>\n<h2 id=\"when-captcha-gets-in-the-users-way\">When CAPTCHA gets in the user&#8217;s way<\/h2>\n<p>Misconfigured CAPTCHA punishes real users. A mobile browser may block third-party cookies, a corporate proxy may interfere with JavaScript, and a screen reader may not be able to complete an image challenge. Users behind one office network or carrier-grade NAT can also look like one suspicious source.<\/p>\n<p>W3C accessibility guidance warns against making visual perception the only way to complete a task. Test keyboard navigation, screen readers, narrow displays, mobile connections, and any audio or alternative verification flow you provide.<\/p>\n<ul>\n<li>Do not offer unlimited attempts after a failed challenge.<\/li>\n<li>Explain whether the form data was preserved and whether a new verification is needed.<\/li>\n<li>For users without JavaScript, consider email verification or manual review where the workflow allows it.<\/li>\n<li>Do not use CAPTCHA as the only control for payments, password resets, or administrator access.<\/li>\n<\/ul>\n<p>A challenge that blocks legitimate users is not a harmless inconvenience. It becomes a support queue and, in some cases, an accessibility failure.<\/p>\n<h2 id=\"privacy-starts-with-the-verification-request\">Privacy starts with the verification request<\/h2>\n<p>A CAPTCHA provider may process an IP address, browser details, cookies, timing information, and interaction data. Read the provider&#8217;s privacy documentation to understand what it collects, how long it retains the data, and whether it shares information with other parties.<\/p>\n<p>Map the data flow rather than stopping at a cookie notice. Which hostname does the browser contact? Which values reach your application with the token? Which identifiers enter your logs? If a reverse proxy is involved, inspect the trusted-header assumptions described in <strong><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-a-proxy-server-and-how-does-it-work\/\">What Is a Proxy Server and How Does It Work?<\/a><\/strong>.<\/p>\n<p>Do not store complete tokens in logs. Retain the provider result, action, timestamp, and a limited rejection reason when you need operational evidence. Mask sensitive values and disable verbose debugging after testing.<\/p>\n<h2 id=\"wordpress-and-nginx-need-endpoint-coverage\">WordPress and Nginx need endpoint coverage<\/h2>\n<p>In WordPress, a plugin that protects the visible login form may leave XML-RPC, REST API, custom AJAX endpoints, comments, or password resets exposed. Compare the protected paths with the application&#8217;s actual request flow. Adding CAPTCHA to the admin page does not replace strong passwords or multifactor authentication.<\/p>\n<p>A small Nginx limit for a login endpoint can look like this:<\/p>\n<pre><code>http {\n    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r\/m;\n\n    server {\n        location = \/wp-login.php {\n            limit_req zone=login_limit burst=3 nodelay;\n            include fastcgi_params;\n            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n            fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n        }\n    }\n}<\/code><\/pre>\n<p>This allows an average of five requests per minute per client address and a short burst of three. The PHP-FPM socket path depends on your distribution and installed PHP version. Do not copy it blindly.<\/p>\n<p>Run <code>nginx -t<\/code> before reloading, then inspect access logs to confirm the behavior:<\/p>\n<pre><code>sudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n<p>If a trusted proxy or CDN makes every visitor appear to come from one address, replacing <code>$binary_remote_addr<\/code> with an incoming header can throttle everyone together. Only use a forwarded client-IP header when it comes from a correctly configured, trusted proxy. For related application resource problems, see <strong><a href=\"https:\/\/www.vps.tc\/blog\/en\/how-to-fix-wordpress-memory-limit-error\/\">How to Fix the WordPress Memory Limit Error<\/a><\/strong>.<\/p>\n<p>Protect every relevant login, registration, comment, and password-reset endpoint. The page displaying the form is not the whole application.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>Protecting only the visible WordPress login form can leave password reset, XML-RPC, REST, or custom AJAX paths exposed. Map the real endpoints before deciding that CAPTCHA coverage is complete.<\/p>\n<\/div>\n<h2 id=\"test-the-failure-paths-not-only-the-checkbox\">Test the failure paths, not only the checkbox<\/h2>\n<p>&#8220;I checked the box and the form submitted&#8221; tells me very little. I test valid, missing, invalid, expired, reused, wrong-site, and timeout cases separately.<\/p>\n<ol>\n<li>Complete the normal flow with a valid token.<\/li>\n<li>Remove the token and send the request directly.<\/li>\n<li>Change the token and inspect the server response.<\/li>\n<li>Attempt the protected action twice with the same token where replay testing is supported.<\/li>\n<li>Force a timeout from the verification service and confirm the application&#8217;s decision.<\/li>\n<li>Compare application and proxy logs after the rate limit is exceeded.<\/li>\n<li>Repeat the flow with a screen reader, keyboard, narrow display, and slow connection.<\/li>\n<\/ol>\n<p>Useful metrics include success and rejection rates, provider response time, application status codes, requests per endpoint, and retry frequency. A sudden rise in rejection can mean an attack, a provider change, or a broken site configuration.<\/p>\n<p>In a hosting environment, I correlate Nginx access logs, PHP-FPM logs, and application logs. CPU is often a late alarm; bots can exhaust connections, sessions, or database pools first.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I once tested only whether a CAPTCHA widget appeared and learned that a visible challenge does not prove the backend is protected. The missing-token and timeout paths deserve their own tests.<\/p>\n<\/div>\n<h2 id=\"mistakes-i-still-look-for-during-review\">Mistakes I still look for during review<\/h2>\n<ul>\n<li>Putting the secret key in frontend code.<\/li>\n<li>Writing form data to the database before verification succeeds.<\/li>\n<li>Confusing the public site key with the server secret.<\/li>\n<li>Allowing unlimited retries after failed challenges.<\/li>\n<li>Trusting an IP header without verifying the proxy that supplied it.<\/li>\n<li>Using CAPTCHA instead of rate limiting.<\/li>\n<li>Writing tokens or unnecessary personal data to plain-text logs.<\/li>\n<li>Requiring a visual test without an accessible alternative.<\/li>\n<li>Changing production configuration without testing it first.<\/li>\n<\/ul>\n<p>If the verification service stops responding, do not open the entire site without limits. Choose queueing, a temporary maintenance response, or a stronger verification step according to the risk of the workflow.<\/p>\n<p>I now test the failure path before enabling a CAPTCHA rule. That habit came from a form that looked secure in the browser and was not secure at the endpoint. The server gets the final say.<\/p>\n<h2 id=\"check-these-before-enabling-captcha\">Check These Before Enabling CAPTCHA<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Verify every protected token on the application server.<\/li>\n<li>Keep provider secrets out of frontend code, Git, shell history, and logs.<\/li>\n<li>Add rate and request-size limits before expensive application work.<\/li>\n<li>Test missing, invalid, expired, reused, wrong-site, and timed-out tokens.<\/li>\n<li>Provide keyboard, screen-reader, mobile, narrow-display, and no-JavaScript alternatives where appropriate.<\/li>\n<li>Review the provider&#039;s data collection, retention, and sharing terms.<\/li>\n<li>Monitor verification results together with proxy, application, and upstream metrics.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>Review one form and its backend endpoint today: verify that the token is checked server-side, rate limiting happens early, and failure logs contain enough context without exposing secrets.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>What is CAPTCHA used for?<\/summary>\n<p>CAPTCHA is used to assess whether a request is likely to come from a human or an automated client. It can reduce automated registrations, spam comments, credential-stuffing attempts, and abusive form submissions. It does not prove human identity, and it cannot stop a bot from consuming resources before verification, so rate limiting and server-side validation remain necessary.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Is CAPTCHA a security feature or a user-experience feature?<\/summary>\n<p>It is both, but neither side is sufficient alone. CAPTCHA adds friction or risk analysis to suspicious actions, while its design determines whether legitimate users can complete the workflow. A challenge that blocks screen-reader users or mobile visitors becomes a security and support problem. Use accessible alternatives and do not treat CAPTCHA as a replacement for authentication or authorization.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can bots bypass CAPTCHA?<\/summary>\n<p>Some bots can bypass or outsource challenges, and others can abuse an endpoint without completing the protected action. CAPTCHA should therefore sit beside rate limiting, account controls, request validation, and monitoring. Keep tokens short-lived according to the provider&#039;s rules, reject replay where supported, verify them on the server, and protect expensive work before the application allocates significant resources.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Should CAPTCHA be verified in JavaScript?<\/summary>\n<p>No. JavaScript can collect a token and submit it, but the browser must not make the final security decision. Your application server should send the token to the provider with the private secret, then check success, hostname or site, action, score, expiry, and provider-specific fields. Only the server should authorize the registration, login, or other protected operation.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Does CAPTCHA replace rate limiting?<\/summary>\n<p>No. CAPTCHA and rate limiting address related but different problems. CAPTCHA evaluates whether a request appears automated, while rate limiting controls how much traffic an identity or source can send over time. An attacker can still generate connections, consume worker processes, or fill a database pool while failing challenges. Put limits at the proxy or application boundary and use CAPTCHA as an additional signal.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Where should CAPTCHA be added in WordPress?<\/summary>\n<p>Start with every action that can create abuse or consume resources: login, registration, comments, password resets, contact forms, and relevant API or AJAX endpoints. Check XML-RPC and REST behavior as well; a plugin may protect only the visible form. Keep administrator access protected by strong authentication and multifactor methods, because CAPTCHA alone is not an administrator security control.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/developers.google.com\/recaptcha\/docs\/verify\" target=\"_blank\" rel=\"noopener\">Google reCAPTCHA &#8211; Verify the User Response<\/a> \u2014 developers.google.com<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc6585\" target=\"_blank\" rel=\"noopener\">RFC 6585 &#8211; Additional HTTP Status Codes<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG22\/Understanding\/non-text-content.html\" target=\"_blank\" rel=\"noopener\">W3C WCAG 2.2 &#8211; Non-text Content<\/a> \u2014 w3.org<\/li>\n<li><a href=\"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_limit_req_module.html\" target=\"_blank\" rel=\"noopener\">NGINX &#8211; ngx_http_limit_req_module<\/a> \u2014 nginx.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>CAPTCHA can make automated abuse more expensive, but it cannot protect an application alone. Learn how server-side verification, rate limiting, privacy, accessibility, and testing fit together.<\/p>\n","protected":false},"author":2,"featured_media":932,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-934","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general"],"lang":"en","translations":{"en":934,"tr":933},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/934","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=934"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/934\/revisions"}],"predecessor-version":[{"id":936,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/934\/revisions\/936"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/932"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=934"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=934"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=934"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}