Your App Works. Now Try Thinking Like an Attacker.

A common beginner mistake is to test only whether an application works as expected.

You create a form, submit valid data, see the success message, and move on.

But what happens when someone submits unexpected data? What if they try to access information that belongs to another user? What if an error message exposes details it should not reveal?

Security-minded development starts by asking what could go wrong.

If you're building your technical foundation in Awka, you can explore practical technology learning at TEKHUB.

Here is a beginner-friendly exercise you can use with a project you own or are explicitly authorised to test.

The scenario

You have built a simple application with a registration form and a user dashboard.

The normal workflow looks like this:

1. A user creates an account.
2. The application validates the submitted information.
3. The user signs in.
4. The dashboard displays the user's information.

Now investigate what happens when the workflow is not followed perfectly.

Test 1: Input validation

Try submitting an empty field, an unexpectedly long value, or data in the wrong format.

Ask yourself: Does the application reject invalid input safely? Does it display a useful error without exposing sensitive implementation details?

Validation should happen on the server where relevant, not only in the browser.

Test 2: Authentication and authorisation

Authentication answers, “Who are you?”

Authorisation answers, “What are you allowed to do?”

These are different questions.

A user being signed in does not automatically mean they should be able to view another user's private information. Ensure the server checks permissions for each protected operation rather than trusting a user interface to hide restricted features.

Test 3: Secrets and sensitive information

Review your project for exposed API keys, passwords, private tokens, and unnecessary personal data.

Do not commit secrets to a public repository. Use environment variables and appropriate secret-management practices, and rotate credentials if they have been exposed.

Test 4: Errors and logging

Trigger an expected failure in your own test environment.

Does the application show a helpful message? Do internal errors expose stack traces or confidential data to users? Are useful diagnostic details recorded securely for developers?

Good error handling should support debugging without giving attackers unnecessary information.

Test 5: Dependencies and updates

Identify the libraries and packages your project depends on. Check for known vulnerabilities, use maintained versions, and understand what a dependency does before adding it.

Security is not something you finish once and forget.

Turn the exercise into a learning project

Write a short README with three sections:

• Finding: What did you discover?
• Impact: Why could it matter?
• Fix: What change did you make, and how did you verify it?

This is useful practice for developers because it connects technical decisions to real risks. It also gives you something concrete to discuss when presenting your work.

Never run security tests against systems you do not own or have explicit permission to assess. For further practice, use deliberately vulnerable applications and authorised training labs.

At TEKHUB, aspiring technology professionals in Awka can explore practical learning and develop the foundations needed to grow in areas such as software development and applied technology.

You don't have to specialise in cybersecurity to benefit from security-minded thinking.

Your challenge: Take one project you have built and perform these five checks. Which issue did you discover first?
Share your experience in the comments.