{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreianfdkygkdxx4eq4u24yesrsmisamyimx2j4hf4v5qtuw75va5mee",
    "uri": "at://did:plc:anldby4lwneunjl777bq6ih7/app.bsky.feed.post/3mhaar337zgh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreieehrdqyn3hljxmr5r74yvojhv4v5ufhdstozxy4b7puzt2nhv7vi"
    },
    "mimeType": "image/png",
    "size": 549206
  },
  "description": "[Tip #128] Do you know the difference between GET and POST requests, and why it's so important that GET requests only ever retrieve data?",
  "path": "/security-tip-stop-putting-actions-on-get-requests/",
  "publishedAt": "2026-03-17T05:33:42.000Z",
  "site": "https://securinglaravel.com",
  "tags": [
    "**Cross-Site Scripting (XSS)**",
    "CSRF",
    "** _Security Tips_**",
    "_**In Depth** articles_",
    "_Laravel Security Audit and Penetration Test_",
    "_Security Reviews_",
    "_Bluesky_",
    "_other socials_"
  ],
  "textContent": "💡\n\n __Note, I'll just be using__ _`_POST_`_ __in this article to keep things simple, but I am talking about all four:___`_POST_`_ __,___`_PUT_`_ __,___`_PATCH_`_ __, and__`DELETE` __.__\n\nLet me ask you a question:\n\n**What is the difference between`GET` and `POST`?**\n\nYou're probably thinking something along the lines of:\n\n_`GET` requests retrieve data from the server, while `POST` requests send data to the server and perform actions. Links use `GET` requests and forms use `POST` requests._\n\nBut what about this question:\n\n**What is the _technical_ difference between `GET` and `POST`?**\n\nSimilar to the above, you're probably thinking:\n\n`GET` _requests can be made entirely from a URL and triggered through links, while_`POST` _requests need to be submitted through a form submission, Javascript, or an API request._\n\nWhile the first answer talks about the flow of data (`GET` - retrieve, `POST` - store) and notes that `POST` requests can perform actions, the second answer makes no mention of actions or security in general.\n\nWhich brings us to the final question:\n\n**What is the difference _in security_ between `GET` and `POST`?**\n\n_`GET` requests can be triggered from unsafe contexts and should never be trusted to perform actions, while `POST` requests have a lot of protections provided by the browser so you can use them safely (mostly)._\n\nSince I think that deserves more of an explanation, let's look at all the ways `GET` and `POST` requests can be triggered maliciously **without****Cross-Site Scripting (XSS)**:\n\n`GET` requests:\n\n  1. Can be triggered by third-party sites through links (`<a>`) that the victim clicks on.\n  2. Can be triggered by third-party sites through resources (`<img>`, `<video>`, etc) that load within the victim's browser.\n  3. Can be triggered by third-party sites through frames (`<iframe>`) that load with the victim's browser.\n  4. Can be triggered through links sent via Direct Messages, Social Media, Email, Chat clients, etc, to the victim's device.\n  5. Can be triggered through seemingly safe tags (`<a>`, `<img>`, etc) inside user submitted content on your website. _(It's not XSS, so your site will load it!)_\n  6. Can be triggered through seemingly safe Markdown as user submitted content on your website. _(Like #5, it's not XSS, so it'll load!)_\n  7. Can be hidden and triggered through redirects and URL shorteners.\n  8. And a few more creative ways...\n\n\n\nConversely, `POST` requests:\n\n  1. Can be triggered from a `<form>` on your site, **IF** you allow users to generate an entire `<form>` inside their submitted content and render it on the page for them... 🤨\n  2. ~~Can be triggered by XSS~~ _Nevermind, I said no XSS above..._\n  3. Can be triggered from a third-party site if you disable CSRF and `SameSite` protections and/or misconfigure CORS... 😱\n\n\n\nOr to reduce the last 400 words down into a single sentence:\n\n**Don't perform actions or state-changing operations on`GET` requests, it's not safe!**\n\nSo go through your apps and check none of your actions are performed via `GET`, even if behind an auth layer. It's an open invitation waiting to be abused.\n\n* * *\n\n**_If you found this security tip useful?_ 👍**\n _Subscribe now_ _to get weekly_** _Security Tips_** _straight to your inbox, filled with practical, actionable advice to help you build safer apps._\n\n**_Want to learn more?_ 🤓**\n _Upgrade to a_ _Premium Subscription_ _for exclusive monthly_ _**In Depth** articles_ _, or support my work with a_ _one-off tip_ _! Your support directly funds my security work in the Laravel community._ 🥰\n\n _**Need a second set of eyes on your code?**\nBook in a __Laravel Security Audit and Penetration Test_ _today! I also offer budget-friendly_ _Security Reviews_ _too._\n\n_Finally, connect with me on_ _Bluesky_ _, or_ _other socials_ _._",
  "title": "Security Tip: Stop Putting Actions on GET Requests!",
  "updatedAt": "2026-03-17T05:33:42.635Z"
}