[{"data":1,"prerenderedAt":145},["ShallowReactive",2],{"publication:en:P153":3},{"meta":4,"copy":16,"relatedArticles":131,"terms":132,"term":133,"resourceParent":139,"glossaryParent":142},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15},"P153","\u002Fglossary\u002Fcsrf","term","what is CSRF","What is CSRF? Forged actions and the authorization boundary","What is CSRF? Request protection and authorization","Understand CSRF, browser credentials, request tokens and authorization. See why a nonce, cookie setting or hidden button is not complete access control.",[13,14],"\u002Fservices\u002Fsecurity-audit","\u002Fservices\u002Fwordpress-security","2026-10-30",{"intro":17,"sections":18,"checklistTitle":87,"checklist":88,"faq":96,"sources":106,"links":109,"cta":126},"CSRF (cross-site request forgery) involves causing a browser to send an unwanted request to an application that may recognize the browser’s existing credentials. The application needs an appropriate way to verify the request’s legitimacy as well as the user’s permission for the action. A logged-in session or a hidden button does not establish both.",[19,24,60,69,74,82],{"title":20,"paragraphs":21},"Identify the state-changing action and its credentials",[22,23],"Start with a business action: changing account settings, modifying a record or requesting another operation. Determine how the application recognizes the caller and which credentials the browser can attach automatically. The concern is a request the person did not intend, accepted under an existing authenticated context. The exact risk depends on the endpoint and browser behavior.","Do not assume that an action is protected because its button appears only to administrators. The server must enforce the relevant controls when a request reaches it. Ask the developer to distinguish sign-in, request-intent protection and authorization. Those are separate questions, and a successful check at one layer does not establish the others.",{"title":25,"paragraphs":26,"sources":29,"table":33},"Check the request defense through the framework’s supported pattern",[27,28],"OWASP describes CSRF defenses that depend on the application's session and request model, including properly validated tokens. The useful review asks where a token comes from, how it is associated with the intended context and what the server does when it is missing or invalid. A token present in a form is not proof that the receiving handler validates it.","Use the framework's maintained protection rather than invent an incompatible token rule. Keep tokens out of URLs and ordinary logs where they can be exposed. A change should include representative authenticated workflows and the browser paths they require. Record the actual endpoint, method and conditions rather than declare every request safe from a single successful submission.",[30],{"label":31,"url":32},"OWASP: CSRF tokens, browser behavior and defense boundaries","https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FCross-Site_Request_Forgery_Prevention_Cheat_Sheet.html",{"caption":34,"headers":35,"rows":39},"Identity, request intent and permission are separate",[36,37,38],"Question","Evidence to inspect","Insufficient observation",[40,44,48,52,56],[41,42,43],"Who is signed in?","Supported session or authentication checks.","A username is shown on the page.",[45,46,47],"Is this request legitimate?","Framework request-defense validation.","A hidden field merely exists in the form.",[49,50,51],"May this identity act?","Server-side role and resource authorization.","The caller has a valid token.",[53,54,55],"What does the browser send?","Relevant cookies, method and origin conditions.","One cookie flag is assumed to cover every path.",[57,58,59],"What was tested?","Allowed and rejected synthetic requests in scope.","A normal successful action alone.",{"title":61,"paragraphs":62,"sources":65},"Understand WordPress nonces without treating them as access control",[63,64],"WordPress calls its security tokens nonces, but its documentation explains that they are not checked for one-time use and should not be relied on for authentication or authorization. They can support protection against unwanted requests while the application still needs the appropriate capability and resource checks.","That distinction matters for custom forms, administrative actions and plugin handlers. A token generated for a page does not authorize every operation a caller might request. Review the server-side handler with the developer and verify the permitted role and target record separately. Do not interpret a token error as evidence that the entire authorization design has been reviewed.",[66],{"label":67,"url":68},"WordPress: nonces and their authorization\u002Freplay limits","https:\u002F\u002Fdeveloper.wordpress.org\u002Fapis\u002Fsecurity\u002Fnonces\u002F",{"title":70,"paragraphs":71},"Treat cookie and browser settings as context, not a shortcut",[72,73],"SameSite settings affect when browsers send cookies and can reduce particular cross-site request paths. OWASP documents important limitations and the need to assess the actual deployment. A cookie setting does not excuse state-changing actions exposed through an unsafe application design or replace a supported request defense by default.","Include legitimate external navigation, embedded applications and provider callbacks in the compatibility review. A browser-session form and a server-to-server webhook may need different authentication models. Do not add a browser token requirement to every integration without understanding how it authenticates, and do not remove protection from an ordinary user action merely because one integration fails.",{"title":75,"paragraphs":76,"example":79},"Verify permitted and rejected actions with synthetic records",[77,78],"Agree the owned environment, test identities and harmless state change before a behavioral check. Confirm the approved workflow works, then verify that the relevant missing, invalid or unauthorized request is rejected under the intended model. Use synthetic records and retain only the evidence needed to describe the boundary; do not include live session tokens in reports.","Record what the test established and which roles or browser conditions remain untested. A secure result should not depend on disabling legitimate business work. If a plugin update changes the behavior, investigate the specific handler and supported controls rather than repeatedly turn off token validation to make the form submit.",{"title":80,"text":81},"Illustrative token-versus-permission gap","A test account sends a valid page token for an action on a record it is not permitted to manage. Request-intent validation alone should not authorize the operation. The application still needs a server-side check of the identity’s permission for that target.",{"title":83,"paragraphs":84},"Maintain request controls across application and integration changes",[85,86],"Revisit the relevant endpoints when a plugin, login method, form or connected service changes. Keep the endpoint owner, request model and acceptance record with the release. XSS and other application weaknesses also need attention because request defenses do not compensate for every way an authenticated browser can be misused.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli knowledge of WordPress, websites and digital infrastructure. We can scope the authorized review and coordinate supported corrections with the application owner. The handover separates the request defense, account permissions and tested business behavior so future changes can preserve the intended protection.","CSRF review questions",[89,90,91,92,93,94,95],"State-changing endpoints and credentials identified","Framework request-defense pattern understood","Server validation checked beyond the form field","Role and resource authorization reviewed separately","WordPress nonce limits understood where applicable","Browser forms distinguished from server-to-server callbacks","Allowed and rejected synthetic actions recorded",[97,100,103],{"question":98,"answer":99},"Is CSRF the same as XSS?","No, CSRF concerns unwanted requests accepted under a browser’s existing credential context. XSS concerns unsafe content becoming browser behavior. They can interact, but each needs its own application controls and evidence.",{"question":101,"answer":102},"Does a valid WordPress nonce authorize an action?","No, WordPress documents that nonces are not authentication or authorization. The handler still needs the appropriate capability and target-resource checks. Token validation and permission validation answer different questions.",{"question":104,"answer":105},"Does changing a form to POST solve CSRF?","Not by itself: review the application’s request-defense model, browser credentials and server-side validation. A request method or hidden button alone does not prove the action was intended or authorized.",[107,108],{"label":31,"url":32},{"label":67,"url":68},[110,113,116,119,122,124],{"path":111,"label":112},"\u002Fglossary\u002Fxss","Distinguish unsafe browser rendering",{"path":114,"label":115},"\u002Fglossary\u002Fleast-privilege","Review permitted actions and resource scope",{"path":117,"label":118},"\u002Fblog\u002Fwordpress-plugin-selection","Review new form and plugin dependencies",{"path":120,"label":121},"\u002Fblog\u002Fwebhook-security","Use the correct model for server callbacks",{"path":13,"label":123},"Scope application control review",{"path":14,"label":125},"Review WordPress security configuration",{"title":127,"description":128,"button":129,"type":130},"Clarify how an important website action is protected","Describe the form, user role and unexpected behavior without sharing session material. We can define the review and acceptance scope.","Discuss request and permission controls","check",[],[],{"name":134,"aliases":135},"CSRF (cross-site request forgery)",[136,137,138],"cross-site request forgery","request forgery","CSRF token",{"path":140,"label":141},"\u002Fresources","Website security resources and templates",{"path":143,"label":144},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134057828]