Overview
Module 6 covers API and token security. It covers API reconnaissance and enumeration, the OWASP API Security Top 10 risks, authorization flaws such as broken object-level and function-level authorization, excessive data exposure, mass assignment, rate-limiting and injection issues, and attacks against JSON Web Tokens (JWT) such as algorithm confusion, weak signing keys, and the none-algorithm flaw.
APIs are now the backbone of most applications, so the CPENT range includes API targets. The module rewards knowing that APIs shift much of the risk to authorization, and that tokens must be validated correctly. A tester who understands JWT structure and common verification mistakes can often bypass authentication entirely.
How it's tested
CPENT is performance-based, so this module shows up as hands-on API testing and token manipulation: enumerating endpoints, probing authorization, and forging or altering tokens, all documented. Because the exam is scored on what you achieve and document on live ranges, read each scenario for what it actually permits and reward methodical, evidence-backed work over guesswork.
-
Probe authorization
You test whether an API enforces object-level and function-level authorization, not just authentication.
-
Attack the token
You inspect and manipulate JWTs, testing signing, algorithm and key weaknesses.
-
Enumerate the API
You discover endpoints, parameters and data exposure through API reconnaissance.
An API returns a user's record at an endpoint that includes a numeric ID. Changing the ID returns another user's record. This is broken object-level authorization, the top API risk, not an injection flaw. The fix is server-side ownership checks on every request. Recognizing it as an authorization failure rather than input manipulation points to the correct exploit and remediation.
Modules 1
Official modules from the EC-Council outline, in outline order.
6.1 API and Java Web Token Penetration TestingThis module covers testing modern APIs and token-based authentication: API reconnaissance, the OWASP API risks, authoriz
- What it means
- API and token testing covers API reconnaissance and enumeration, the OWASP API Security Top 10, authorization flaws (broken object-level and function-level authorization), excessive data exposure, mass assignment, rate-limiting gaps, and JWT attacks such as algorithm confusion, the none algorithm, and weak signing keys.
- What to understand
- APIs shift much risk to authorization: the same request from a different user should not return another's data. JWTs carry claims and a signature; servers that fail to verify the signature, accept the none algorithm, or use weak keys can be bypassed. Reconnaissance reveals undocumented endpoints and parameters.
- How it shows up
- Applied hands-on to enumerate APIs, probe authorization and manipulate tokens on the range.
- Common confusion
- Treating API authorization flaws as injection; broken object-level authorization is a missing ownership check, not code injection.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Broken object-level authorization
An API returns objects without checking ownership.
- Remember
- The top API risk; test by changing IDs.
- Tested as
- API authorization.
- Trap
- Treating it as injection.
-
Broken function-level authorization
An API lets a user call privileged functions.
- Remember
- Test lower-privileged access to admin actions.
- Tested as
- API authorization.
- Trap
- Assuming the UI hides the function enforces it.
-
Excessive data exposure
An API returns more data than the client needs.
- Remember
- Clients should not rely on filtering the response.
- Tested as
- API data risk.
- Trap
- Trusting the client to hide fields.
-
Mass assignment
Binding client input to object fields that should be protected.
- Remember
- Attackers set fields like isAdmin.
- Tested as
- API input risk.
- Trap
- Allowing unrestricted property binding.
-
JWT structure
Header, payload and signature, base64url-encoded.
- Remember
- The signature protects integrity.
- Tested as
- Token basics.
- Trap
- Trusting the payload without verifying the signature.
-
JWT none algorithm
A token claiming no signature algorithm.
- Remember
- Servers must reject none.
- Tested as
- JWT attacks.
- Trap
- Accepting none-algorithm tokens.
-
JWT algorithm confusion
Tricking a server into verifying with the wrong key type.
- Remember
- It can forge valid-looking tokens.
- Tested as
- JWT attacks.
- Trap
- Not pinning the expected algorithm.
-
Weak signing keys
Short or guessable JWT secrets.
- Remember
- They allow offline brute-forcing.
- Tested as
- JWT attacks.
- Trap
- Using weak HMAC secrets.
-
API reconnaissance
Discovering endpoints, parameters and documentation.
- Remember
- It reveals undocumented attack surface.
- Tested as
- Enumeration.
- Trap
- Testing only documented endpoints.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
API authorization vs. authentication vs. injection
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Broken authorization | Failing to check what a user may access | Returns others' data or functions | Treating it as injection |
| Broken authentication | Failing to verify who the user is | Allows impersonation | Confusing it with authorization |
| Injection | Untrusted input interpreted as a command | Alters queries or commands | Confusing it with authorization flaws |
JWT weaknesses
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| None algorithm | Token with no signature | Server must reject it | Accepting unsigned tokens |
| Algorithm confusion | Wrong key type used to verify | Enables forgery | Not pinning the algorithm |
| Weak signing key | Guessable secret | Allows offline cracking | Using short HMAC secrets |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Authz is injection
- What candidates pick
- Classify an ID-swapping data leak as SQL injection.
- Why it looks right
- Both involve manipulating a parameter.
- Why it's wrong
- Returning another user's object by changing an ID is broken object-level authorization.
Clue to watch for Changing an identifier returns data belonging to another user.
-
UI hides the function
- What candidates pick
- Assume an admin function is safe because the UI hides it.
- Why it looks right
- Users cannot see it.
- Why it's wrong
- If the API does not enforce function-level authorization, the call still works.
Clue to watch for A lower-privileged user can call a privileged endpoint directly.
-
Trust the payload
- What candidates pick
- Act on JWT claims without verifying the signature.
- Why it looks right
- The claims look authoritative.
- Why it's wrong
- Unverified or none-algorithm tokens can be forged; the signature must be validated.
Clue to watch for The server accepts a modified token.
-
Client filters data
- What candidates pick
- Rely on the client to hide extra fields an API returns.
- Why it looks right
- The UI does not display them.
- Why it's wrong
- Excessive data exposure means the sensitive fields are in the response regardless of the UI.
Clue to watch for The raw API response contains more than the UI shows.
-
Documented only
- What candidates pick
- Test only the endpoints listed in the API documentation.
- Why it looks right
- They are known and easy.
- Why it's wrong
- API reconnaissance reveals undocumented endpoints that often carry the real risk.
Clue to watch for Hidden or versioned endpoints exist beyond the docs.
Answer framework
For any CPENT API and Java Web Token Penetration Testing scenario, use these steps.
- Enumerate the API through reconnaissance, discovering documented and undocumented endpoints and parameters, working methodically and documenting the outcome before moving on.
- Probe authorization first, testing object-level and function-level checks by changing IDs and calling privileged endpoints.
- Inspect tokens, decoding JWTs and testing signature verification, the none algorithm and weak keys.
- Check for excessive data exposure and mass assignment in requests and responses.
- Exploit and chain the strongest flaw, usually an authorization or token bypass, and document the impact, and record evidence and the reasoning for each decision as you go, since the engagement is judged partly on the professional report you submit at the end.
Practice question
Want more like this? The CPENT practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
APIs behave differently from classic web apps, so study authorization first: most serious API flaws are failures to check what a user may access, not injection. Practice changing object IDs and calling privileged endpoints to find broken object-level and function-level authorization.
Then master JWTs. Learn the three-part structure and the common verification mistakes, the none algorithm, algorithm confusion and weak signing keys, and practice forging or cracking tokens in a lab. API reconnaissance is the third pillar: undocumented and versioned endpoints often carry the real risk, so never test only the documented surface. Afterwards, move to Module 7, network penetration testing, which covers the external, internal and perimeter network layers. Throughout, keep a disciplined note-taking and evidence workflow, because the CPENT report and its evidence carry much of the score, and details are easily lost across a long, intense exam. Rehearse this in a lab until it is routine, and capture evidence as you work so the final report is complete and defensible.
FAQ
Why is authorization the biggest API risk?
APIs often authenticate a user but fail to check that the user may access a specific object or function, so changing an ID or calling a hidden endpoint exposes others' data or privileged actions.
What is a JWT and why attack it?
A JSON Web Token carries claims and a signature. If a server fails to verify the signature, accepts the none algorithm, or uses a weak key, an attacker can forge tokens and bypass authentication.
What is broken object-level authorization?
An API flaw where the server returns an object based on an identifier without checking that the requester is allowed to access it.
What is mass assignment?
Binding client-supplied input to internal object fields that should be protected, letting an attacker set fields such as an admin flag.
Why test undocumented endpoints?
Reconnaissance often reveals hidden or older API versions that lack the controls of the documented interface and carry real risk.
Is an API flaw ever injection?
Yes, APIs can have injection too, but the signature API risks are authorization failures, which are distinct from injection and need different fixes.
How does this module connect to the rest of CPENT?
APIs and tokens often protect the same back-end systems targeted in web, cloud and network modules, so a token bypass can unlock wide access.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Practice Module 6 skills
You have covered API reconnaissance, authorization flaws and JWT attacks. Practice probing authorization and manipulating tokens hands-on.