Skip to content
CodeKruPro

Check effective headers and inherited authentication

Automation taskMediumAsked in: Capgemini, Infosys

Interviewers ask how you set authentication once for many requests. This lesson uses authorization set on the collection and shows how to check what each request really sends.

Check effective headers and inherited authentication

05 · Check permissions and share the collection

Recommended first: Check that one customer cannot access another’s data

Your goal: Check effective headers and inherited authentication

Follow one request at a time. Send it yourself, then select that response before you answer.

  1. 1Send requests
  2. 2Submit answers

Start here: sign in to practise.

Jump to practice

What you will learn

You have already used Basic, API-key and bearer authentication. Return to your Postman collection to see how a parent setting can be inherited or overridden. The effective outgoing headers are the evidence, not the saved setting name.

Your goals

  • Set parent authentication and a request override in Postman.
  • Inspect outgoing headers and preserve a safe reusable structure.

Before you start

Read the previous lesson first if you have not already. This course does not require programming.

Practice setup

These requests use the public TestKru teaching API. No workspace is needed unless a step says so. Leave the body empty for GET, HEAD and OPTIONS. Example people and emails are fictional. Changes to /api/users are simulated and are not saved.

Follow these steps

  1. In Beginner API Lab, add a protected request GET https://testkru.com/api/auth/protected. Obtain a fresh teaching token using POST /api/auth/login and the public teaching credentials from the earlier bearer-token lesson. Keep the token in a local Postman variable named practiceToken.
  2. Set collection Authorization to Bearer Token with value {{practiceToken}}. Set the protected request to Inherit auth from parent. Send it. Inspect the outgoing Authorization header in the Postman Console.
  3. Duplicate the protected request and set its Authorization to No Auth. Send it, inspect the headers and compare the response. Remove any manually added Authorization header so it cannot override the experiment.
  4. For the console evidence on this page, repeat the Basic and API-key controls shown in the guide. Record statuses and investigate the error disclosure. These logs verify those requests, not your external Postman session.
  5. Clear practiceToken before exporting. Remove any saved login request containing a password, or clear its password body value. Delete saved login response examples containing token or refreshToken. Export the collection as v2.1 JSON. Submit the export showing parent bearer auth, an inherited protected request and a No Auth protected request. Never submit a working token.

Investigate before concluding

First record the actual result for each case. Compare the body, headers and later state with the stated contract. Keep an observation separate from a prediction; use the model answer only after making your own attempt.

What to keep as evidence

  • Present and missing credentials are separate requests.
  • The API key is sent in a header, not the URL.
  • The finding does not repeat the secret.
References for this lesson

Finish this assignment

Select each named response with Use this response. Answer from those responses or the transcript on this page. Click Submit Answers. Your score is the percentage of checks that passed. Core checks are required to finish. Extra evidence checks are labelled. A saved 100/100 means every check passed. Continue opens the next lesson you can submit.

If something goes wrong
  • Change one part of the request at a time. If a check needs attention, read the note under it and compare it with the response you selected.
Self-review and independent variation
  • Present and missing credentials are separate requests.
  • The API key is sent in a header, not the URL.
  • The finding does not repeat the secret.

Change one saved auth setting and predict which requests would send the new value.

Automatic checks verify the requests and answers configured for this lesson. The self-review is for your own reasoning. A score is not a certificate.

Open API reference

Practise and save your evidence

The lesson is public. Sign in to send requests and save progress. You will return to this lesson.

Sign in to practiseCreate an account