Burger Singh · Authentication Profile
Burger Singh Authentication
Authentication
Burger Singh secures its APIs with none, cookie, and http-basic across 3 declared security schemes, as derived from its OpenAPI definitions.
CompanyRestaurantsQuick Service RestaurantFood and BeverageFranchisingConsumerIndiaRetailContentWordPress
Methods: none, cookie, http-basic
Schemes: 3
OAuth flows:
API key in:
Security Schemes
public-read none
wordpress-cookie-nonce cookie
· in: cookie ()
application-passwords http
scheme: basic
Source
Authentication Profile
generated: '2026-08-08'
method: probed
source: live anonymous probes of https://www.burgersinghonline.com/wp-json/ (2026-08-08)
summary:
types:
- none
- cookie
- http-basic
api_key_in: []
oauth2_flows: []
notes: >-
Burger Singh publishes no developer program and no product API. Its only machine-readable
surface is the platform-provided WordPress REST API at /wp-json/ behind burgersinghonline.com,
and the read half of that surface is fully public: every operation documented in this repo's
openapi/ specs was verified to return HTTP 200 with JSON to an anonymous request carrying no
credentials of any kind. There is no API key, no OAuth, no signup, and no rate-limit or quota
signalling was observed. Unlike a default WordPress install the root index does advertise one
authentication method - `application-passwords`, with its authorization endpoint at
/wp-admin/authorize-application.php - but that is an administrative site credential issued to a
logged-in WordPress user, not a public developer credential, and there is no self-serve path to
obtain one. Write operations (POST/PUT/PATCH/DELETE) are registered on the same routes but
reject anonymous callers; they require a logged-in WordPress session cookie plus an X-WP-Nonce
header, or an Application Password over HTTP Basic. Those write operations are deliberately NOT
documented in the openapi/ specs, which describe only the anonymously reachable read surface.
schemes:
- name: public-read
type: none
description: >-
Anonymous public read access to the WordPress content API - pages, media, categories, tags,
search, public authors, the Yoast SEO head endpoint, and the type/taxonomy/status registries.
evidence: >-
GET /wp-json/wp/v2/pages?per_page=1 returned 200 with page JSON and X-WP-Total: 20; the same
anonymous request pattern returned 200 on media (X-WP-Total: 576), categories (13), tags (0),
comments (0), search, users (1), types, taxonomies, statuses and yoast/v1/get_head.
- name: wordpress-cookie-nonce
type: cookie
in: cookie
description: >-
WordPress core cookie authentication paired with an X-WP-Nonce request header, required for the
write half of the same routes and for the administrative read routes. Not a public developer
credential - it belongs to a logged-in site user.
evidence: >-
Access-Control-Allow-Headers on /wp-json/wp/v2/pages advertises `Authorization, X-WP-Nonce,
Content-Disposition, Content-MD5, Content-Type`. Anonymous GETs against the administrative
routes returned 401 (see gated_surface below).
- name: application-passwords
type: http
scheme: basic
description: >-
WordPress Application Passwords over HTTP Basic, declared in the root index `authentication`
object. Issued interactively to an existing WordPress user at the authorization endpoint below;
there is no public registration or self-serve issuance.
authorization_endpoint: https://www.burgersinghonline.com/wp-admin/authorize-application.php
evidence: >-
The live root index at /wp-json/ returns
{"authentication":{"application-passwords":{"endpoints":{"authorization":"https://www.burgersinghonline.com/wp-admin/authorize-application.php"}}}}.
gated_surface:
description: >-
Routes present in the live route table but not anonymously readable. Recorded so the
public/private split of this surface is explicit rather than inferred. Every status and code
below was observed on 2026-08-08.
routes:
- path: /wp/v2/settings
status: 401
code: rest_forbidden
- path: /wp/v2/themes
status: 401
code: rest_cannot_view_themes
- path: /wp/v2/plugins
status: 401
code: rest_cannot_view_plugins
- path: /wp/v2/menus
status: 401
code: rest_cannot_view
- path: /wp/v2/block-types
status: 401
code: rest_block_type_cannot_view
- path: /wp/v2/templates
status: 401
code: rest_cannot_manage_templates
- path: /wp/v2/pages/{id}/revisions
status: 401
code: rest_cannot_read
- path: /wp-abilities/v1/abilities
status: 401
code: rest_forbidden
note: >-
The WordPress Abilities API - the agent-facing capability registry - is registered on this
host but is entirely credentialed. No ability names, descriptions or input schemas are
readable anonymously, so none are recorded in this repo.
- path: /wp-site-health/v1/tests/https-status
status: 401
code: rest_forbidden
- path: /psd/v1/get-logs
status: 401
code: rest_forbidden
- path: /contact-form-7/v1/contact-forms
status: 403
code: wpcf7_forbidden
- path: /post-smtp/v1/get-logs
status: 400
code: 'Auth token missing.'
note: >-
Plugin route with a non-WordPress error envelope - returns
{"success":false,"data":{"error":"Auth token missing."}} rather than the core code/message/data
shape.
docs: https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
x-evidence:
fetched: '2026-08-08'
host: https://www.burgersinghonline.com
root_index: https://www.burgersinghonline.com/wp-json/
http_status: 200
namespaces: 12
routes_advertised: 200
authentication_field:
- application-passwords