Web server, application and API security · Lesson 5 of 6
Check web permissions, input handling and sessions
About 16 minutes · Introductory draft · Checked 2026-10-22
AI editorial review for introductory study; independent review and complete exam alignment remain pending. Read course scope and remaining gaps.
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
What you will learn
- Distinguish server hardening from application authorization.
- Explain injection, output encoding and safe query construction.
- Assess sessions and access control with designated test accounts.
Look beyond the login screen
A web server exposes an application through protocols and configuration. Patch supported components, disable unnecessary features and protect administrative interfaces. These steps do not repair a business logic flaw in the application. Each request for a record or action needs server-side authorization, including API requests.
For an approved access-control exercise, use two designated test accounts with separate synthetic records. Check that each account can use its own permitted resources and cannot access the other’s restricted resources. Hiding a button or using unpredictable record identifiers is not a substitute for enforcing the permission on the server.
Keep data separate from instructions
Injection occurs when untrusted input changes the meaning of an interpreter’s instructions. Parameterized database queries separate query structure from supplied values. Validation checks that input fits the expected type and business rules, but a client-side check alone can be bypassed by a direct request.
Cross-site scripting involves untrusted content being treated as active page content. Context-appropriate output encoding and safe rendering APIs help keep data from becoming executable markup or script. The protection needed for database queries differs from the protection needed when rendering HTML; one universal filter is not a complete design.
Protect the session and the result
A session token represents an authenticated session and needs confidentiality, limited lifetime and appropriate invalidation. Secure cookie settings, protected transport and server-side session handling work together. A password change or logout needs the intended session behavior; a visual logout screen alone does not prove the token is invalid.
Record the request context and minimal synthetic response needed to explain a finding. Keep real tokens out of reports and screenshots unless explicitly necessary and securely handled. Agree a retest that covers the corrected case and legitimate user behavior, because a fix that denies every user is not a useful success.
Work through a scenario
Fictional facts for learning. This exercise is not scored.
Account A can retrieve account B’s synthetic invoice by changing a record identifier. The page hid B’s invoice link. What failed?
Compare your reasoning
Server-side object authorization failed. The server must verify that the requesting identity is allowed to access that invoice on every relevant request. Hiding links or making identifiers longer does not provide the missing authorization check. Retest both cross-account denial and each owner’s permitted access.
Applied study · Added 2026-10-22
Distinguish authorization, injection and session failures
Continue beyond the introduction. Work through the evidence before opening the model answer.
See it · Try it · Recall it
Picture the topic
Remember this: Secure the host the service and the exposed path.
Explore the anchors
Patch and restrict operating-system access.
Concept matching activity
Match this task or description to its concept:
Harden the web-server configuration.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
Visual recap for topic 5.1. Open its full syllabus chapter.
Treat every object operation as an authorization decision
An application must decide whether the caller may perform the requested action on the specific object. Hiding a button or using an unpredictable identifier does not establish that decision. Test horizontal boundaries between users and vertical boundaries between privilege levels with approved synthetic accounts. Separate authentication failures from object-authorization failures in the report. A demonstration needs only enough evidence to show the missing boundary; downloading a production dataset is unnecessary when two controlled records establish the issue.
Choose corrections that address the root condition
Parameterized database operations separate query structure from untrusted values; input validation and output encoding solve related but different problems. Session protections include secure transport, appropriate cookie settings, token lifecycle and revocation. A rate limit can reduce abuse volume but does not correct a missing permission check. Retest server-side behavior for both permitted and denied requests, including alternate endpoints that reach the same object. Maintain clear limits: this lesson explains assessment reasoning, not instructions to test a real service without authorization.
Evidence case
Fictional facts for learning; no real organization or person is described.
- Two approved staging users own separate invoices. User A can retrieve user B’s synthetic invoice by changing the object identifier.
- The developer proposes hiding invoice identifiers in the browser and adding a per-minute request limit.
Your task
- Identify the demonstrated control failure.
- Specify a correction and two retest cases.
Compare with the model answer
This is an object-level authorization failure. Enforce the caller’s permission on the server for each invoice operation. Test that A can retrieve A’s invoice and receives an appropriate denial for B’s invoice, then check related update or export endpoints within scope. Obscuring identifiers and limiting request rate may reduce convenience or volume, but neither makes the forbidden object access authorized. Keep the demonstration limited to the two synthetic invoices.
This case has two original scenario questions in the expanded practice bank. Practice this course · Edition, coverage and remaining study
Remember
- Enforce permission for each resource and action on the server.
- Parameterized queries and output encoding address different interpreters.
- Test intended session invalidation and preserve minimal synthetic evidence.
Orientation and further reading
- EC-Council: CEH course overview and modules
- NIST SP 800-115: planning and assessing security tests
- OWASP: Web Security Testing Guide project
- RST Forum: curriculum comparison reference
- RST Forum: provider lab comparison reference
Original examples and explanations. Background references do not establish complete exam coverage.