Web Security and OWASP Concepts for Beginners
Understand access, input handling and evidence within an authorised lab.
Part of the Cybersecurity track: modules, projects and first roles →
By the GullyMentor team · 5 min read · Published 2026-10-18 · Updated 2026-11-06 · Sources listed at the end. Not a promise about mentorship outcomes.
Web security makes sure an application lets the right person do the right thing with the right data. Beginners should learn authentication, authorisation, input handling and safe configuration, using the OWASP Top 10 as a guide. Practise only in a local training app that you run yourself, such as OWASP Juice Shop.
How do I start?
1. Read the current OWASP Top 10 pages once, slowly. Treat the list as a set of questions to ask, and check the official site for the latest edition because it is revised over time. 2. Learn how HTTP requests and responses work, and how cookies or tokens identify a logged-in user. 3. Run a training application on your own computer. OWASP Juice Shop is an intentionally vulnerable app designed for this. Follow its official instructions, and make sure it listens only on your local machine, not on a public network. 4. Write a one-page scope: what you will test, what you will not, and when you will stop.
OWASP provides educational resources about application-security risks. Use them as a guide to questions, not as proof that a checklist covers every risk.
A worked example: two users, one rule
Suppose a shop app shows each user their own orders. The intended rule is simple: a user may see only their own orders.
- Create two synthetic accounts in your local app. Place one order on each.
- Write down the rule and what a correct denial looks like.
- While logged in as the first account, check, within your written scope, whether the app lets this user open the second account's order. Record what the server returned.
- If the rule is not enforced, the defensive fix is for the server to check ownership on every request, not to hide a link in the page. Describe that fix and repeat the check after it.
Authentication and authorisation
Authentication establishes an identity. Authorisation decides what that identity may do. A logged-in user should not automatically gain access to another user's records.
In a local training app, create two synthetic accounts and document the intended access boundary. Test only the behaviour allowed by your lab scope. Record the expected and observed results without sharing credentials.
Input and trust
Applications receive data from forms, URLs, files and other systems. Treat external input according to its context. Validation, safe database interfaces and context-appropriate output handling solve different parts of the problem.
A filter that removes one suspicious word is not a general security design. Explain where data goes and what controls apply there.
Configuration and exposure
Review whether unnecessary functions, debug output or sensitive files are exposed. Consider permissions and how errors are displayed. A helpful error should not reveal secrets.
Use a disposable environment and keep intentionally vulnerable applications away from public networks.
Evidence and severity
Describe what you observed, the access required and the affected scope. Distinguish a possible risk from a demonstrated impact. Do not inflate severity because a scanner assigned a dramatic label.
Recommend a correction and define a retest. Keep evidence proportionate and sanitised.
Practice task
Write a one-page lab scope, inspect one access-control behaviour and produce a short finding report. Include expected behaviour, observed evidence, impact assumptions and remediation.
If no issue is found, report the check and its limits. “No finding in this exercise” is more accurate than “the application is secure”.
The essential habit is to connect a security claim to authorised evidence and a useful defensive action.
What are the common mistakes?
- Confusing being logged in with being allowed to see a particular record.
- Trusting a hidden button or a client-side check as a security control. The server must decide.
- Believing a scanner's severity label without understanding the impact.
- Running a vulnerable training app on a shared or public network.
- Writing "the application is secure" after one clean check.
How do I check I got it?
Without notes, explain the difference between authentication and authorisation with an example from your lab. Then show your one-page finding: expected behaviour, observed evidence, assumptions, fix and retest result. If a reader can repeat your check and reach the same conclusion, your report works.
What should I build next?
Turn the exercise into a portfolio piece using cybersecurity projects for an authorised lab. To see where web security fits among other roles, read cybersecurity roles explained. The cybersecurity track covers the full path.
Sources & further reading
Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.