Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: basic-auth policy rejects valid credentials when the Authorization scheme is not spelled exactly "Basic"

Open Beginner friendly
#3,882 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go

Research direction

The affected code is policies/basic-auth/basicauth.go in wso2/gateway-controllers; the issue also names the existing policies/basic-auth test helper and comparison examples in the JWT and opaque-token policies. Read the basic-auth header parsing and run the supplied TestZZScheme reproduction. Done when all four equivalent Authorization headers authenticate successfully and the policy tests pass.

Written by the indexing model from the issue text.

Description

Aspect/API Severity/Minor Type/Bug
Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

The basic-auth policy (wso2/gateway-controllers, policies/basic-auth/basicauth.go, policy version v1.0.3) checks the scheme with a case-sensitive prefix match:

if !strings.HasPrefix(authHeader, "Basic ") {
    return p.handleAuthFailureHeaders(...)
}
encodedCredentials := strings.TrimPrefix(authHeader, "Basic ")

RFC 9110 section 11.1 says the authentication scheme is a case-insensitive token, and that the credentials may follow after one or more spaces (credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]). As a result:

  • A client that sends basic <base64> or BASIC <base64> with the correct username and password gets 401 Unauthorized. Some HTTP libraries, hand-written scripts and older devices send the scheme in lower case.
  • A client that puts two spaces after the scheme also gets 401 Unauthorized.

The JWT and opaque-token policies in the same repository already compare the scheme case-insensitively (jwt-auth/jwtauth.go: strings.EqualFold(parts[0], scheme); opaque-token-auth/opaquetokenauth.go does the same), so the gateway's auth policies behave differently from each other.

Note: filed in wso2/api-platform because wso2/gateway-controllers, where the policy lives, has issues disabled.

Steps to Reproduce

On wso2/gateway-controllers main c5d83e0, add this test to policies/basic-auth and run go test -run TestZZScheme -v .. It uses the package's existing newBasicRequestHeaderContext helper.

func TestZZScheme(t *testing.T) {
	cred := base64.StdEncoding.EncodeToString([]byte("admin:secret"))
	for _, h := range []string{"Basic " + cred, "basic " + cred, "BASIC " + cred, "Basic  " + cred} {
		ctx := newBasicRequestHeaderContext(map[string][]string{"authorization": {h}})
		a := ins.OnRequestHeaders(context.Background(), ctx, map[string]interface{}{"username": "admin", "password": "secret"})
		switch v := a.(type) {
		case policy.ImmediateResponse:
			fmt.Printf("%-40q -> %d %s\n", h[:8], v.StatusCode, v.Body)
		default:
			fmt.Printf("%-40q -> allowed (authenticated=%v)\n", h[:8], ctx.SharedContext.AuthContext.Authenticated)
		}
	}
}

Expected behavior

All four headers carry the same valid credentials (admin:secret), so all four are authenticated.

Actual behavior

"Basic YW"  -> allowed (authenticated=true)
"basic YW"  -> 401 {"error":"Unauthorized","message":"Authentication required"}
"BASIC YW"  -> 401 {"error":"Unauthorized","message":"Authentication required"}
"Basic  Y"  -> 401 {"error":"Unauthorized","message":"Authentication required"}
Severity Level of the Issue

Severity/Minor (Non-critical functionality. Can be fixed in future releases)

Environment Details (with versions)
  • wso2/gateway-controllers main c5d83e0 (basic-auth policy v1.0.3, sdk/core v0.3.4)
  • Go 1.27.2, Debian Linux x86_64
Dominant language
Go
Stars
76
Forks
126
Avg merge
2d 8h
Merged PRs (30d)
181

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wso2/api-platform

All issues in wso2/api-platform

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.