URLs, Path and Query Parameters

Why it matters

Parameters are input fields that the interface hides. Search terms, IDs, filters and page numbers travel in the URL, so they need the same test design as a form field. Handled badly, a search for "tea & coffee" returns the wrong products, a filter is silently ignored, or changing /orders/1001 to /orders/1002 shows another customer's order: Broken Object Level Authorization, the first risk in the OWASP API Security Top 10 2023.

Editing a URL is also the fastest way to try an input or reproduce a report, and the exact encoded URL is the most precise evidence a bug report can carry.

The five parts of a URL

RFC 3986 defines the generic syntax of a URI in five parts: scheme://authority/path?query#fragment. Each part ends at a fixed delimiter, so you can split any URL by hand; the WHATWG URL Standard, which browsers follow, splits it the same way.

The client uses the scheme and authority to connect, sends the path and query as the request target, and puts the host in the Host header. The fragment never leaves the browser, so no server log or API test sees it.

• Scheme: https or http; it also sets the default port, 443 or 80.
• Authority: the host, such as shop.example.com, and an optional :port. Scheme and host are not case-sensitive.
• Path: /stores/riyadh-01/products, segments separated by / that identify the resource.
• Query: everything after ? up to #.
• Fragment: everything after #, such as #reviews: a position in the page or a route inside a single-page app.

https://shop.example.com/stores/riyadh-01/products?q=green%20tea&page=2#reviews

scheme      https
authority   shop.example.com             (no port: 443, the https default)
path        /stores/riyadh-01/products
query       q=green%20tea&page=2
fragment    reviews                      (stays in the browser)

What the server receives:
GET /stores/riyadh-01/products?q=green%20tea&page=2 HTTP/1.1
Host: shop.example.com

Try it: URL Parser

Path parameters: which resource

RFC 3986 only knows path segments. "Path parameter" is the API-design name for a segment whose value changes per request: the documentation writes a template, /stores/{storeId}/products, and each request fills it in. OpenAPI marks it in: path; websites use the same idea for slugs like /products/green-tea-500g.

A path parameter identifies the resource, so it is required: /stores//products reaches another route or none. A wrong type, such as /orders/abc for a numeric ID, should get a 4xx client error, not a 500; an unknown ID should get 404; and another user's ID must never return that user's data. An encoded slash %2F in the value is handled differently by different servers, so ask what is intended and test it.

Query parameters: how to read the resource

The query refines the request: search, filter, sort, paginate. RFC 3986 only defines where it starts and ends; the key=value pairs joined by & come from the HTML form format application/x-www-form-urlencoded, defined in the WHATWG URL Standard and followed by most frameworks. Query parameters are usually optional with defaults, so an absent parameter is behaviour too. Each of these is a different input:

• ?page=2: a key with a value.
• ?page= or ?page: present but empty, not the same as leaving page out.
• ?tag=tea&tag=gifts: a repeated key. No standard says which value wins; frameworks take the first, the last or all of them.
• ?Page=2: many frameworks compare keys case-sensitively, so this may be an unknown key that is silently ignored.

Try it: Query String Parser

Percent-encoding: keeping values intact

RFC 3986 reserves the characters that structure a URL: : / ? # [ ] @ separate the parts, and ! $ & ' ( ) * + , ; = separate data inside them. The letters A to Z and a to z, the digits 0 to 9 and - . _ ~ never need encoding. Every other character in a value, including a space, should be percent-encoded: each byte becomes % and two hexadecimal digits.

Characters outside ASCII, the basic set of 128 Latin letters, digits, symbols and control codes, are first turned into bytes with UTF-8, the character encoding of the web: an ASCII character takes one byte, any other character two to four. The Arabic word قهوة (coffee) is four letters of two bytes each, so it is sent as eight encoded bytes: %D9%82%D9%87%D9%88%D8%A9. Encode each value, never the whole URL, or / and ? turn into %2F and %3F and the URL breaks.

• + means a space only in form-encoded data, which is how most servers read a query; in a path it is a plus sign. Encode a real plus as %2B, or +966… arrives as a space followed by 966….
• Encode once and decode once: %2520 is a space encoded twice, and a server that decodes twice may let an encoded character slip past its input validation.

Value           Encoded query value
green tea       green%20tea
tea & coffee    tea%20%26%20coffee
50%             50%25
#1 seller       %231%20seller
+966500000000   %2B966500000000
قهوة            %D9%82%D9%87%D9%88%D8%A9

Try it: URL Encoder Try it: URL Decoder

Worked example: testing a product list URL

Requirement: GET /api/v1/stores/{storeId}/products lists a store's products. q is an optional search term; sort is price_asc (the default) or price_desc; page is an integer from 1, default 1; limit is an integer from 1 to 50, default 20. An unknown store gets 404; an invalid parameter value gets 400 with a message naming the parameter.

Two test design techniques do most of the work, and each has its own lesson that covers it in depth: equivalence partitioning splits a parameter's values into partitions, groups that the system should treat the same way, such as valid and invalid limit values, and tests one value from each; boundary value analysis then tests the value at each edge of a partition and its nearest neighbour across that edge, such as limit=50 and limit=51. Apply both to each parameter, then add the URL cases: missing, empty, repeated, unknown and encoded values. Expected results:

• No query: 200, page 1, at most 20 products, cheapest first.
• Unknown store riyadh-99: 404, not an empty list or a 500.
• limit=50 is accepted; limit=51 gets 400 with a message naming limit. Add limit=1 and limit=0 for the lower boundary.
• page=0, page=abc and sort=newest: 400, never a 500 or an undocumented fallback.
• The searches must decode to "tea & coffee" and قهوة and return matching products. Repeat them in the user interface and check the DevTools Network tab: a page that joins strings sends q=tea%20&%20coffee, and the server reads q as "tea " plus a stray key.
• Repeated page and unknown debug: the expected result must come from the documentation; if nothing is written, ask.

GET /api/v1/stores/riyadh-01/products
GET /api/v1/stores/riyadh-99/products
GET /api/v1/stores/riyadh-01/products?limit=50
GET /api/v1/stores/riyadh-01/products?limit=51
GET /api/v1/stores/riyadh-01/products?page=0
GET /api/v1/stores/riyadh-01/products?page=abc
GET /api/v1/stores/riyadh-01/products?sort=newest
GET /api/v1/stores/riyadh-01/products?q=tea%20%26%20coffee
GET /api/v1/stores/riyadh-01/products?q=%D9%82%D9%87%D9%88%D8%A9
GET /api/v1/stores/riyadh-01/products?page=2&page=3
GET /api/v1/stores/riyadh-01/products?debug=true

Try it: API Query Parameter Builder Try it: Special Character Dataset Generator

Frequently asked questions

References

• RFC 3986: Uniform Resource Identifier (URI): Generic SyntaxIETF · 2005The parts of a URI (scheme, authority, path, query, fragment), reserved characters and percent-encoding.
• URL StandardWHATWGHow browsers actually parse, serialize and encode URLs, including application/x-www-form-urlencoded.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.