The Movement to Ban URL Query Strings: 5 Reasons Developers Should Know

Do you think it's just standard practice to attach parameters like ?id=123&user=abc to a URL? I was one of those people who believed that for a long time, and in casual code reviews, I would often write, 'I'll just pass this via a query string' without a second thought☕.

But recently, I read an article by Chris Morgan titled 'no-query-strings,' and it really made me think. From the perspective of privacy and security, that 'standard practice' might be quietly starting to waver. Today, I'd like to gently break down this trend for you🌿.

Is a wave of banning query strings coming? The latest trends in the developer community 💭

To begin with, the phrase 'banning query strings' sounds a bit extreme, doesn't it? In fact, it was sparked by a claim titled 'I've banned query strings' that became a hot topic on overseas developer blogs, and the discussion seems to be gradually spreading through developer communities like Hacker News✨.

By the way, as of May 2026, it doesn't seem like any specific large-scale projects have declared a 'total ban'; it's mostly centered around experimental efforts by individual developers and small teams. Even so, why is it getting so much attention?

There seem to be about three trends in the background🍀.

• Strengthened tracker countermeasures by browser vendors (Safari's ITP, Firefox's ETP, etc.)

• Discussions by Google Chrome regarding the handling of utm_ parameters

• Design philosophies driven by GDPR and revised personal information protection laws to 'not send unnecessary data'

I feel like the entire web is gradually steering toward a direction of 'not including unnecessary information in URLs.'

Privacy Infringement and Security Risks: The Dangers of Query Strings 🫧

This is probably the most important part.

The problem with query strings is their nature of being 'easily left in logs.' Server access logs, browser history, Referer headers, CDN cache keys, internal proxies... just listing them off the top of my head, there are so many places where they get recorded.

At first, I also thought, 'It's HTTPS, so it's encrypted, right?' But actually, HTTPS only encrypts the communication path; once it reaches the server, it remains in the logs as plain text. For example, if you include an authentication token like ?token=xxxxx, it could end up being stored in a place accessible to any operations staff.

OWASP guidelines have also long warned against including sensitive information in query strings. Specifically, the following risks are cited.

• Information leakage risk: Parameters leaking to external sites via the Referer header

• Caching accidents: CDNs or shared proxies caching individual URLs

• Tracking abuse: Tracking via fbclid, gclid, etc.

• Log pollution: Personal information being stored in access logs for long periods

Of course, not all query strings are evil. There are situations where they are functionally necessary, such as search keywords or pagination (?page=2). I feel the mainstream of the current discussion is not a 'total ban' but rather a 're-evaluation of where to use them'.

Real-world examples: How major companies and browsers are responding 🌸

It's much easier to visualize with concrete examples, isn't it?

For instance, Apple's Safari has reportedly implemented a feature since around 2020 that automatically removes utm_ tracking parameters passed via links. Firefox also seems to have added a feature called "Query Parameter Stripping" to remove unnecessary parameters during private browsing 🕊.

The Brave browser is even more proactive, reportedly removing a wide range of tracking parameters by default.

Come to think of it, GitHub also uses a clean path design for its URL structure, such as /{user}/{repo}/issues/{number}, and uses query strings only for "truly necessary situations" like filtering or searching. Looking at the Stripe API documentation, the policy of always including authentication information in the Authorization header is strictly enforced.

On the other hand, there are valid counterarguments. Some say, "If you restrict query strings, you won't be able to perform A/B testing or get detailed analytics," or "The marketing department won't be able to function." Honestly, I think that's true. Balancing privacy and business operations is truly difficult.

Do alternatives really work? How to utilize URL paths and headers ✨

So, if we are to reduce query strings, how should we rewrite them? Personally, I think three approaches are realistic.

1. Conversion to URL paths

This is a method of expressing resource hierarchy, such as /products/shoes/red instead of /products?category=shoes&color=red. It works well with RESTful design and is said to be advantageous for SEO as well.

2. Utilizing HTTP headers

It is standard practice to put authentication tokens and session information in the Authorization header or Cookie. It is less likely to remain in logs, and the risk of leakage via Referer is significantly reduced 💫.

3. POST + body transmission

When search conditions are complex or highly confidential, there is also the option of taking the plunge and using POST to send them in the request body. Although it has the weakness of not being bookmarkable like GET, the security of the data is said to be significantly improved.

However, there are strong counterarguments here too: "If you strictly follow RESTful principles, operations without side effects like searching should be GET," and "Caching won't work if you use POST."

I also once got enthusiastic and changed my design to "Let's make everything a path!" only to end up making even pagination /page/2/, which didn't mesh with the frontend library, leading to a huge failure 🌷. The lesson is: "Don't try to replace everything; prioritize reviewing highly confidential items first." Moving forward gradually seems to be the fastest way in the end.

Web development from now on: How should we face query strings? 🍀

Having read this far, you might be wondering, "So what should I actually do?"

In my personal opinion, rather than deciding to "ban" them entirely, I think using them differently based on the type of information is a gentle middle ground.

• Confidential information/authentication information → to headers or body

• Resource Identifiers → URL Paths

• Filtering, Searching, Pagination → Query Strings are OK

• Tracking Purposes → Avoid if possible, or use Cookies or Measurement APIs

Perhaps in a few years, we will look back with a bit of nostalgia, saying, "Remember when we used to line up parameters in URLs?" Technology trends have a way of shifting quite fluidly, don't they?

I hope you will use this as a reference and make decisions based on the specific circumstances of your own projects 🌿.

Conclusion 🌷

What did you think about the discussion on query strings? You might have been surprised by the strong word "ban" at first, but I feel the essence is a call to "think about user privacy and safety a little more carefully."

You don't need to rewrite everything starting with tomorrow's commit; just reviewing the URL of one new implementation is a sufficient first step ✨. The accumulation of small choices might be what builds a more secure web for everyone. Why not take a fresh look at the URLs in your project?

Reference Links

• Chris Morgan "no-query-strings"

• MDN Web Docs - GET method query strings

• W3C URL Specification - Query String

What are your thoughts?
Please let me know in the comments if you'd like.
Please also follow and like the post♪

For feedback on this article, questions, or business inquiries,
please feel free to send me a message♪
📩 Send messages here
https://note.com/alvis8039/message

#WebSecurity #PrivacyProtection #URLDesign #WebDevelopment #CyberSecurity #QueryString #APIDesign #REST #WebArchitecture #TechTrends #InformationSecurity #ForDevelopers #HTTP #DataLeakPrevention #BrowserTrends #MustReadForEngineers #ImplementationGuide #BestPractices #NextGenWeb #TechExplanation