DEV Community: Qnayds Career

When AI Writes the Code: Who Is Responsible for Security?

Qnayds Career — Tue, 01 Sep 2026 05:25:47 +0000

AI coding assistants have changed the way developers work.

A developer can describe a feature, generate a function, fix an error, or even create an entire component in a few seconds. It can save a lot of time.

But there is an important question that doesn't get enough attention:

What happens when AI-generated code contains a security problem?

The answer is simple: the developer is still responsible for the code.

AI Can Write Working Code That Isn't Secure

One of the interesting things about AI-generated code is that it can look completely reasonable.

A function may work exactly as expected while still creating a security weakness.

For example, an AI assistant might generate code that:

Trusts user input too much
Handles authentication incorrectly
Exposes sensitive information in error messages
Uses insecure defaults
Stores secrets in the wrong place
Gives users more access than they should have

The problem isn't necessarily that AI "doesn't know security."

The problem is that generated code needs to be reviewed in the context of the actual application.

Security Review Should Become Part of the Workflow

Instead of thinking:

AI generated the code, so the code is finished.

A better workflow is:

Generate → Review → Test → Secure → Deploy

AI can help with the first step, but security requires human judgment.

Developers should understand what the generated code is doing before adding it to a production application.

Look Beyond Syntax

A normal code review often asks questions like:

Does the code work?
Is it readable?
Is it efficient?
Does it follow the project's style?

A security review asks additional questions:

Can an attacker control this input?
What happens if authentication fails?
Can another user access this resource?
Is sensitive information exposed?
What permissions does this function require?
What happens when unexpected data is supplied?

These questions are where cybersecurity becomes part of everyday development.

AI Can Also Help With Security

This doesn't mean developers should avoid AI coding tools.

Quite the opposite.

AI can be useful for:

Explaining unfamiliar code
Finding potential security issues
Suggesting validation improvements
Generating test cases
Reviewing repetitive code
Explaining security concepts

But AI should be treated as an assistant, not the final security authority.

The Developer Still Needs to Understand the Code

This is probably the most important lesson.

If you cannot explain what a piece of generated code does, you probably shouldn't deploy it yet.

The more AI becomes part of software development, the more valuable security awareness becomes.

Writing code is becoming easier.

Understanding why that code is safe is still a human responsibility.

*A Simple Rule
*
Before deploying AI-generated code, ask:

"If someone deliberately tries to misuse this feature, what could go wrong?"

That one question can lead to a surprisingly useful security review.

AI can accelerate development.

It shouldn't accelerate mistakes.

Developers who combine AI productivity with strong cybersecurity practices will be in a much better position as software development continues to change.

Why Children Shouldn't Copy AI Answers Blindly

Qnayds Career — Fri, 28 Aug 2026 09:29:34 +0000

AI has become a normal part of how many students search for information, do homework, learn new topics, and even write assignments.

And honestly, AI can be really useful.

The problem starts when a student assumes that everything an AI tool says must be correct.

AI can give a confident-looking answer even when the information is incomplete, outdated, biased, or simply wrong. UNICEF has also highlighted over-reliance on AI and the possible effect on children's critical-thinking skills as an important concern.

AI Doesn't "Know" Everything

When a child asks an AI tool a question, the answer may look very convincing.

There may be a detailed explanation, examples, and even sources.

But that doesn't automatically make it true.

AI systems can sometimes generate incorrect information, often called AI hallucinations.

For example, imagine a student asks:

"Who invented the internet?"

The AI might provide a simplified or misleading answer.

If the student simply copies it into an assignment, they may never realize that the answer needs to be checked.

That's why one of the most important AI skills for children isn't learning complicated prompts.

It's learning to question the answer.

Don't Replace Thinking With Copy and Paste

Imagine a student has a maths problem.

Instead of trying to understand it, they immediately ask AI for the solution, copy the answer, and submit it.

The homework is finished.

But what did the student actually learn?

The next time a similar problem appears without AI, they may struggle.

AI should ideally help children understand difficult subjects, not do all the thinking for them.

UNICEF recommends that children learn to use AI as a complement to their own abilities rather than as a substitute for their input and thinking.

AI Can Be a Great Teacher — If Used Properly

This doesn't mean children shouldn't use AI.

Quite the opposite.

AI can be useful for learning when it's used as a tool.

For example, instead of asking:

"Give me the answer."

A student could ask:

"Explain this concept in simple language."

Or:

"Give me a similar problem so I can practice."

Or:

"I tried solving this problem. Can you explain where my reasoning went wrong?"

These types of questions encourage the student to participate in the learning process.

The goal should be:

Think → Ask AI → Check → Understand

Not:

Ask AI → Copy → Submit

Always Verify Important Information

Children should develop the habit of checking important information using reliable sources.

For example, if AI gives an answer about:

History
Science
Current events
Health
Technology
School assignments

they shouldn't automatically assume it's accurate.

They can compare the information with textbooks, trusted websites, teachers, libraries, or other reliable sources.

UNICEF's recent research on children and AI found that children can over-trust AI tools, while regular verification of AI-generated information remains relatively uncommon among some young users.

That makes verification an important digital skill.

AI Images Can Be Misleading Too

It's not only text that children need to question.

AI can now create incredibly realistic images, videos, and audio.

A picture that looks real may not actually show a real event.

A person's voice can potentially be recreated.

A video can be manipulated.

This makes media literacy increasingly important.

Children should learn to ask:

Who created this?

Where did it come from?

Can I find another reliable source confirming it?

Does the information actually make sense?

Learning these habits can help them avoid falling for misinformation and manipulated content.

AI Should Make Children More Curious, Not Less

One of the biggest benefits of technology is that it can make learning easier and more accessible.

But there's a difference between making learning easier and removing the learning process completely.

If a child uses AI to understand a difficult concept, that's useful.

If they use AI to avoid thinking about the concept at all, that's a problem.

The goal isn't to keep children away from AI.

The goal is to teach them how to use it intelligently.

A Simple Rule for Children

A simple rule that parents and teachers can teach is:

Stop → Think → Check

Stop: Don't immediately trust or share the AI answer.

Think: Does the answer make sense? Do I understand it?

Check: Can I confirm it using another reliable source?

This small habit can make a big difference.

The Skill That Will Matter Most

AI tools will continue to become better.

Children will probably use them in school, college, work, and everyday life.

So teaching them to simply use AI isn't enough.

They also need to learn how to question AI, verify information, protect their privacy, recognize misinformation, and make their own decisions.

UNICEF's guidance on AI and children emphasizes preparing and skilling children for AI while supporting transparency, safety, privacy, fairness, and children's development.

The future probably won't belong to people who never use AI.

It will belong to people who know when to use AI, when to question it, and when to think for themselves.

And that's a skill worth teaching children early.

Why Security Logs Matter More Than You Think

Qnayds Career — Tue, 18 Aug 2026 10:12:47 +0000

When a security incident happens, one of the first questions a security team asks is simple:

“What actually happened?”

The answer is often hidden inside logs.

Web servers, applications, firewalls, authentication systems, cloud platforms, and databases can generate thousands of log entries every day. The challenge isn't collecting logs — it's knowing which events matter.

What Can Security Logs Reveal?

A properly configured logging system can help identify:

Repeated failed login attempts
Suspicious IP addresses
Unusual login locations
Privilege changes
Unexpected API requests
Access to sensitive files
Configuration changes
Abnormal traffic patterns

For example, imagine an administrator account suddenly logs in from a new country at 3 AM and immediately changes several user permissions.

One event might not look particularly dangerous.

Several related events appearing within a few minutes could tell a completely different story.

This is where security monitoring becomes important.

Don't Just Collect Everything

A common mistake is treating logging as a storage problem.

More logs don't automatically mean better security.

Organizations need to decide which events are important enough to monitor and how long those records should be retained.

Authentication events, administrative actions, security alerts, API activity, and access to sensitive resources usually deserve particular attention.

Logs Need Context

A failed login isn't necessarily an attack.

Five failed attempts from an employee who forgot their password may be normal.

Thousands of attempts against multiple accounts from the same source are much more interesting.

Security teams therefore look at patterns rather than isolated events.

This is one reason SIEM platforms and automated detection systems are useful. They can correlate events from different systems and help analysts identify activity that would be difficult to notice manually.

Protect the Logs Too

There's another important point: security logs themselves need protection.

If an attacker gains access to a system and can simply delete or modify its logs, investigating the incident becomes much harder.

Access to logs should therefore be restricted, retention policies should be defined, and important records should ideally be stored separately from the systems generating them.

A Practical Approach

Even a small organization can improve its visibility by starting with a few important areas:

Monitor authentication activity.
Record administrative changes.
Track access to sensitive resources.
Review unusual network activity.
Protect log storage from unauthorized modification.
Establish a reasonable retention period.
Create alerts for genuinely suspicious patterns.

Cybersecurity isn't only about preventing attacks.

It's also about being able to understand what happened when something goes wrong.

Good logging provides that visibility.

Whether you're building a web application, managing a small business network, or working on a larger infrastructure, treating logs as an important part of your security strategy can make incident detection and investigation significantly easier.

What Happens Inside a Website When You Click ‘Login’

Qnayds Career — Tue, 11 Aug 2026 09:43:12 +0000

We click Login dozens of times without thinking about what happens afterward.

You enter your email.

You enter your password.

You click the button.

A second later, you're inside your account.

But behind that simple button is a chain of communication between your browser, the web server, the authentication system, the database, and the session-management layer.

Understanding this process is also a great way to understand where web security problems can occur.

*1. You Enter Your Credentials
*
Let's say you're logging into:

https://example.com/login

You enter:

Email: user@example.com
Password: ********

Your browser now needs to send this information to the website.

But before that happens, there are several things going on behind the scenes.

*2. Your Browser Finds the Server
*
When you visit a website, your browser needs to know where that website actually lives.

This involves DNS (Domain Name System).

In simple terms:

example.com
↓
DNS lookup
↓
IP address
↓
Web server

DNS helps translate the human-readable domain name into an IP address that computers can use to communicate.

*3. HTTPS Creates an Encrypted Connection
*
Before your login information is transmitted, the browser establishes a secure connection using HTTPS/TLS.

This is extremely important.

Without encryption, sensitive information could potentially be exposed while travelling between the browser and server.

HTTPS doesn't mean the website itself is automatically secure, but it protects the communication channel between the browser and server.

For authenticated sessions, OWASP recommends using HTTPS for the entire session, not just the initial login request.

*4. Your Browser Sends an HTTP Request
*
Now the interesting part happens.

Your browser sends a request to the server.

A simplified example might look like:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{
"email": "user@example.com",
"password": "********"
}

The actual request depends on how the application was built.

It might use a traditional form submission or send the credentials through an API request.

*5. The Server Receives the Request
*
The request reaches the web application's backend.

The server doesn't simply say:

"The password looks right."

Instead, the application performs several checks.

It may check:

Does the account exist?
Is the account active?
Is the login request valid?
Are there rate limits?
Does the supplied password match the stored password hash?
Are additional authentication factors required?

This is where authentication takes place.

Authentication is essentially the process of verifying that someone is who they claim to be.

*6. The Password Isn't Supposed to Be Stored as Plain Text
*
This is an important security concept.

A properly designed application shouldn't store:

password = "MyPassword123"

in its database.

Instead, passwords should be stored using a password-hashing system designed for this purpose.

Conceptually:

User Password
↓
Password Hashing
↓
Stored Password Hash

When you log in later, the application verifies the supplied password against the stored password hash.

The goal is to make sure that even if the database is compromised, the stored password values aren't simply readable passwords.

*7. The Database Gets Involved
*
The application may query its database to find the account.

Something conceptually like:

Find account where email = user@example.com

The database might return information such as:

User ID
Password Hash
Account Status
Role
MFA Settings
Other Account Data

The application then uses this information to determine whether authentication should succeed.

This is one reason secure database queries matter. Developers should use appropriate parameterized queries or framework mechanisms rather than constructing unsafe SQL from user input.

*8. What Happens If the Password Is Correct?
*
Suppose everything checks out.

You're authenticated.

But there's still a problem.

HTTP itself is stateless.

In other words, the server doesn't automatically "remember" that you logged in when you make your next request.

That's where sessions come in.

*9. Your Website Creates a Session
*
The server can create a unique session identifier for your authenticated session.

Think of it like this:

The browser then sends the session identifier with subsequent requests.

The server uses it to associate those requests with your authenticated account.

OWASP describes session management as the mechanism that allows a web application to maintain state across multiple HTTP requests.

*10. The Browser Stores a Cookie
*
A common way of maintaining a web session is through cookies.

The server might send something conceptually similar to:

Set-Cookie: session_id=abc123...

Your browser stores the cookie and sends it with future requests to the appropriate website.

Then when you visit:

/account

the browser sends the session information.

The server can use it to determine:

"This request belongs to the authenticated user."

A properly designed session identifier should be unpredictable and should not contain sensitive information.

11. You Can Now Access Your Account

The next time your browser requests:

GET /dashboard

the request can include your session cookie.

The server checks the session and determines your identity and permissions.

Then it sends the dashboard back to your browser.

So what looked like:

Click → Login

was actually more like:

You click Login
↓
Browser creates request
↓
DNS / network communication
↓
HTTPS/TLS connection
↓
Web server
↓
Authentication
↓
Database lookup
↓
Password verification
↓
Session creation
↓
Cookie/session token
↓
Authenticated request
↓
Dashboard

That's a lot happening for one button click.

*Where Can Things Go Wrong?
*
This is where cybersecurity becomes particularly interesting.

Every stage introduces potential security considerations.

*Authentication
*
Weak authentication controls can make accounts easier to compromise.

Password Storage

Poor password storage can expose users if a database is breached.

Session Management

If session identifiers are improperly handled, attackers may be able to impersonate users.

OWASP notes that disclosure, capture, prediction, or fixation of session IDs can lead to session hijacking.

Authorization

Even after authentication succeeds, the application still needs to determine what the user is actually allowed to access.

Being logged in doesn't mean you're an administrator.

APIs

Modern applications often use APIs behind the login page. Those APIs need their own proper authentication and authorization controls.

Cookies

Session cookies should be configured carefully. Attributes such as Secure, HttpOnly, and appropriate SameSite settings can help protect session cookies.

What About “Remember Me”?

Ever wondered why some websites keep you logged in even after you close the browser?

That's usually handled through a longer-lived authentication mechanism.

Instead of asking for your password every time, the application can use a persistent credential or session mechanism.

But there's a trade-off.

The longer an authentication credential remains valid, the longer an attacker could potentially use it if it is stolen.

That's why secure applications need sensible expiration, revocation, and session-management strategies.

What Happens When You Click Logout?

Logout isn't simply:

"Close the page."

A proper logout process should invalidate the authenticated session or otherwise make the credential unusable.

After logout, trying to access protected resources should require authentication again.

This is another reason session management is such an important part of web security.

The Security Lesson

The most interesting thing about a login page isn't the button itself.

It's everything behind it.

A secure login system involves several layers:

Browser
↓
HTTPS
↓
Web Server
↓
Authentication
↓
Password Verification
↓
Database
↓
Session Management
↓
Authorization
↓
Protected Resources

A weakness in one layer can affect the security of the entire application.

That's why cybersecurity isn't just about finding vulnerabilities with tools.

It's also about understanding how normal applications are supposed to work.

Once you understand the normal flow, security problems become much easier to recognize.

Final Thoughts

The next time you click Login, remember that you're triggering a surprisingly complicated process.

Your browser is communicating with a server.

The server is verifying your identity.

A database is involved.

A session is established.

Your browser receives authentication information.

And every subsequent request needs to be associated with the correct user and permissions.

That's the hidden world behind a button that looks completely ordinary.

And honestly, that's one of the things that makes web security so interesting.

The better you understand how something works normally, the easier it becomes to understand how it can fail.

8 Security Mistakes Developers Make Without Realizing It

Qnayds Career — Mon, 10 Aug 2026 09:23:02 +0000

When building an application, it's easy to focus on whether the feature works.

The login works.
The API returns data.
The payment page loads.

But security problems often hide in the parts we don't think about.

I've seen developers make some of these mistakes simply because they were trying to get the application working first. Here are a few worth checking in your own projects.

1. Hardcoding API Keys

Putting something like this directly in your source code is asking for trouble:

API_KEY = "your-secret-key"

Even if you remove it later, the key may still exist in Git history.

Use environment variables or a proper secrets manager instead.

And if a secret has already been exposed, don't just delete the line. Rotate the key.

2. Trusting User Input

Never assume that data coming from a user is safe.

A username, email address, search query, uploaded file, or form field can contain unexpected input.

Validate input on the server side and use appropriate output encoding and parameterized queries.

Client-side validation is useful for user experience, but it should never be your only security control.

*3. Returning Too Much Data From an API
*
Sometimes an API returns an entire database object when the frontend only needs two fields.

For example:

{
"name": "John",
"email": "john@example.com",
"password_hash": "...",
"internal_id": 12345
}

The frontend may only need the name and email.

Return only what the client actually needs.

This reduces accidental information exposure.

*4. Forgetting Authorization Checks
*
Authentication answers:

"Who are you?"

Authorization answers:

"Are you allowed to do this?"

A user being logged in doesn't automatically mean they should be able to access every resource.

For example:

GET /api/users/102/profile

The server should verify that the current user is actually allowed to access that profile.

Don't rely on hiding buttons in the frontend.

The backend needs to enforce permissions.

*5. Weak Password Storage
*
Passwords should never be stored as plain text.

If your database is compromised, plaintext passwords immediately become a major problem.

Use a password hashing algorithm designed for password storage, such as Argon2id, bcrypt, or scrypt, with appropriate configuration.

And remember: encryption and password hashing are not the same thing.

*6. Ignoring Security Headers
*
HTTP security headers can provide another layer of protection.

Depending on your application, consider headers such as:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy

You don't necessarily need every header blindly.

Understand what each one does and configure it according to your application's requirements.

*7. Leaving Debug Features Enabled
*
Debugging tools are useful during development.

They can also expose sensitive information.

Before deploying to production, check whether your application is accidentally exposing:

Stack traces
Environment variables
Internal paths
Database errors
Debug endpoints
Development credentials

Production should not behave like your local development environment.

*8. Never Testing the Security Side
*
You don't need to become a penetration tester to start testing your application's security.

Try asking simple questions:

What happens if this parameter is changed?
Can one user access another user's data?
What happens with invalid input?
Can an unauthenticated user access this endpoint?
What happens after logging out?
Are sensitive values appearing in browser storage or logs?

These basic checks can reveal surprisingly serious problems.

*A Simple Pre-Deployment Checklist
*
Before pushing an application to production, take a few minutes to check:

[ ] No secrets in source code
[ ] User input is validated
[ ] Database queries use parameters
[ ] Authorization is enforced server-side
[ ] Passwords are securely hashed
[ ] Sensitive data isn't exposed through APIs
[ ] Debug mode is disabled
[ ] Security headers are configured
[ ] Dependencies are updated
[ ] Error messages don't reveal internal information

Security isn't something that should be added after the application is finished.

The earlier you think about it, the easier it becomes to build it into the application naturally.

You don't have to know every security technique on day one. Start by understanding how your application handles input, authentication, authorization, data, and errors.

Those five areas alone can teach you a lot about secure development.

What should I expect when studying cyber security?

Qnayds Career — Sat, 08 Aug 2026 11:08:36 +0000

We usually hear about AI in the context of chatbots, image generators, coding assistants and automation.

But sometimes the most interesting AI projects have nothing to do with a chatbot.

They involve a camera, a difficult real-world problem and an attempt to build something that can actually help people.

Recently, our founder Rishan NK received coverage in Malayalam newspapers for an AI-camera initiative focused on wildlife monitoring.

Seeing a technology project like this receive attention made me think about something that is easy to forget when working in tech:

Technology is most valuable when it solves a problem outside the laptop.

*The Problem Isn't Just "Detect an Animal"
*
At first, an AI wildlife camera sounds simple.

Put a camera somewhere.

Point it at an area.

Use AI to identify animals.

Done.

But real-world technology rarely works that way.

Imagine placing a camera near farmland.

The camera may see a person in the morning, a dog a few minutes later, birds flying past, leaves moving in the wind, vehicles, changing sunlight and eventually a wild animal.

The system needs to distinguish between all these different situations.

That's where things become interesting.

AI Meets the Real World

With a computer, we can control almost everything.

The lighting is predictable.

The data is clean.

The environment doesn't suddenly change.

Outside, none of that is guaranteed.

A wildlife-monitoring camera has to deal with real environmental conditions.

Rain.

Darkness.

Movement.

Different distances.

Different angles.

And sometimes objects partially hidden behind vegetation.

This is very different from simply running an AI model on a prepared dataset.

Why I Find This Approach Interesting

What I like about projects like this is the mindset behind them.

Instead of asking:

"What can we do with AI?"

the better question is:

"What problem around us could AI help solve?"

That change in thinking can lead to completely different projects.

A student learning AI might build another chatbot.

That's fine.

But they could also look around their own community and ask:

Can AI help farmers?

Can computer vision help monitor crops?

Can technology help detect hazards?

Can AI help with environmental monitoring?

Can sensors and software work together to solve a local problem?

Suddenly, learning technology becomes much more interesting.

From Learning to Building

One thing I have noticed while working around technology is that there is a big difference between knowing a technology and using it to build something useful.

You can learn Python.

You can learn machine learning.

You can learn computer vision.

You can learn electronics.

But eventually, the question becomes:

What are you going to build with those skills?

That is where projects become valuable.

They force you to deal with problems that tutorials don't always show you.

AI Doesn't Have to Be Complicated to Be Useful

There is sometimes a tendency to think that an AI project needs to use the latest and most complicated model to be impressive.

I don't think that's necessarily true.

If a relatively simple system can provide useful information at the right time, it can have more practical value than a technically impressive model with no real-world purpose.

The goal should not always be:

"Build the most advanced AI."

Sometimes it should be:

"Build something that actually helps."

A Lesson for Students

If you're learning AI, cybersecurity, software development or any other technology, try looking beyond tutorials.

Find a problem around you.

It doesn't have to be a huge global problem.

It could be something affecting your local community, a business, a school, farmers or the environment.

Then ask yourself:

Can technology make this a little better?

That's often where the best project ideas begin.

Final Thought

The interesting thing about AI isn't just what happens inside a computer.

It's what happens when that intelligence is connected to the real world.

A camera.

A sensor.

A piece of software.

A local problem.

And someone willing to experiment.

That's when technology starts becoming more than something we learn.

It becomes something we build.

What I Learned After Building My First Secure Web App

Qnayds Career — Thu, 06 Aug 2026 08:21:49 +0000

When I built my first web application, I was mainly focused on one thing:

"Make it work."

If users could sign up, log in, and use the application, I considered it a success.

Security wasn't something I paid much attention to.

Looking back, that was probably the biggest mistake I could have made.

Here's what I learned after building my first secure web application—and why I think every developer should learn at least the basics of web security.

Security Isn't Something You Add Later

At first, I treated security like polishing the UI.

I thought I'd finish development first and "secure it later."

The problem?

Many security issues are deeply connected to how your application is designed.

Things like:

Authentication
Authorization
Session management
Database queries
API design

These are much easier to build correctly from the beginning than to fix later.

Passwords Should Never Be Stored Directly

This sounds obvious now.

But when I first started learning backend development, I didn't fully understand why everyone talked about hashing passwords.

Then I learned an important lesson:

If your database is compromised, plain-text passwords become everyone's problem.

Modern applications should hash passwords using trusted algorithms like bcrypt or Argon2 rather than storing them directly.

Input Validation Is More Important Than I Expected

Every input coming from a user should be treated as untrusted.

That includes:

Proper validation helps prevent issues such as:

SQL Injection
Cross-Site Scripting (XSS)
Command Injection

It also improves application stability.

HTTPS Isn't Optional

Early in development I mostly tested locally, so HTTP seemed fine.

But in production?

HTTPS protects data while it's travelling between users and your server.

Without it, sensitive information could potentially be intercepted.

Today, there's almost no reason not to enable HTTPS.

Authentication and Authorization Are Different Things

This was one of my biggest learning moments.

Authentication answers:

"Who are you?"

Authorization answers:

"What are you allowed to do?"

A user being logged in doesn't automatically mean they should have access to every page or every API endpoint.

Every protected resource should verify permissions.

Error Messages Can Leak Information

While debugging, I loved detailed error messages.

Attackers do too.

Showing full stack traces, SQL errors, or internal server details can reveal useful information about your application.

Now I keep detailed logs on the server while returning simple, user-friendly messages to visitors.

Dependencies Need Regular Updates

Modern web apps rely on dozens (sometimes hundreds) of third-party packages.

Those packages occasionally contain vulnerabilities.

Keeping dependencies updated isn't just about getting new features.

It's part of maintaining a secure application.

Never Trust Client-Side Validation Alone

JavaScript validation improves user experience.

It doesn't improve security.

Attackers can bypass browser validation completely.

Anything important should always be validated again on the server.

Security Headers Matter

Before learning web security, I had never heard of headers like:

Content Security Policy (CSP)
X-Frame-Options
X-Content-Type-Options
Strict-Transport-Security

These small configuration changes provide an extra layer of protection against several common attacks.

Security Is a Continuous Process

This was probably the biggest lesson.

There isn't a point where you can say:

"My application is now completely secure."

New vulnerabilities are discovered regularly.

Libraries change.

Frameworks evolve.

Attack techniques improve.

Building secure software means continuously learning, testing, and improving.

If I Started Again...

Here's what I'd do differently from day one:

✅ Design authentication properly

✅ Use secure password hashing

✅ Validate every input

✅ Keep dependencies updated

✅ Enable HTTPS

✅ Apply security headers

✅ Review permissions carefully

✅ Test before deployment

Final Thoughts

Building my first secure web application completely changed the way I write code.

Now, whenever I create a feature, I don't just ask:

"Does it work?"

I also ask:

"Can someone abuse this?"

That small shift in mindset has probably improved my applications more than any framework or programming language ever could.

If you're just getting started with web development, don't wait until after deployment to think about security.

The earlier you build secure habits, the easier they'll become.

*What About You?
*
What's the biggest security lesson you've learned while building a web application?

I'd love to hear your experience in the comments.

How Hackers Actually Find Vulnerable Websites (Legally Explained)

Qnayds Career — Wed, 05 Aug 2026 09:55:22 +0000

When people hear the word "hacker," they often imagine someone randomly breaking into websites.

In reality, professional penetration testers and ethical hackers follow structured methodologies—and only test systems they have permission to assess.

Let's look at how vulnerability discovery actually works.

Step 1 — Gathering Information

Before touching a target, security professionals collect publicly available information.

This process is called reconnaissance.

Examples include:

DNS records
Subdomains
Public technologies
Open-source information
Public documentation

This phase helps understand the target's attack surface.

Step 2 — Technology Fingerprinting

Next comes identifying what technologies the website uses.

Common questions include:

Which web server is running?
Which CMS is installed?
Which programming language is used?
Which JavaScript frameworks are present?

Knowing the technology stack helps determine what kinds of issues might exist.

Step 3 — Automated Vulnerability Scanning

Security professionals often use scanners to identify common weaknesses.

These tools may detect:

Missing security headers
Outdated software
Misconfigurations
SSL/TLS issues
Exposed services

Automated tools save time but don't replace manual testing.

Step 4 — Manual Testing

Many vulnerabilities require human analysis.

Examples include:

Authentication logic flaws
Business logic issues
Authorization problems
Session handling weaknesses

Manual testing is where experience matters most.

Step 5 — Validating Findings

Not every scanner result is a real vulnerability.

Ethical hackers verify findings carefully before reporting them.

False positives are common, especially in automated scans.

Step 6 — Documentation

Professional penetration testing isn't just about finding vulnerabilities.

It's also about producing clear reports that include:

Risk level
Evidence
Reproduction steps
Business impact
Remediation recommendations

Good documentation is often more valuable than the vulnerability itself.

What Ethical Hackers Don't Do

Contrary to movies, ethical hackers don't randomly attack websites.

They only test systems when:

They have written permission
The organization owns the system
They're participating in bug bounty programs
They're working inside controlled lab environments

Testing systems without authorization is illegal in many jurisdictions.

Skills That Matter More Than Fancy Tools

Many beginners focus on learning dozens of tools.

In reality, experienced security professionals spend more time understanding:

Networking
HTTP
Web applications
Operating systems
Authentication
Programming basics

Tools change frequently, but strong fundamentals remain valuable.

Final Thoughts

Finding vulnerabilities isn't about "hacking faster." It's about understanding how systems work, thinking like an attacker, and following a disciplined, legal testing methodology.

If you're beginning your cybersecurity journey, spend time building a strong foundation before jumping into advanced tools. Consistent learning and practice are far more valuable than chasing the latest exploits.

If you're looking for beginner-friendly cybersecurity articles and learning resources, you can also explore https://qnayds.in.

Can ChatGPT Help You Learn Cybersecurity? Here's the Honest Answer

Qnayds Career — Tue, 04 Aug 2026 10:53:36 +0000

AI is changing the way we learn. But can ChatGPT really teach you cybersecurity, or is it just another overhyped tool?

If you've spent even a few minutes on tech forums or LinkedIn, you've probably seen people saying things like:

"I learned ethical hacking with ChatGPT."
"AI will replace cybersecurity training."
"Just ask ChatGPT anything."

The truth is somewhere in the middle.

ChatGPT is one of the best learning assistants available today—but it's not a replacement for real practice.

Let's break it down.

What ChatGPT Is Really Good At

Think of ChatGPT as a personal tutor that's available 24/7.

Instead of spending hours searching through websites, you can ask questions directly.

For example:

"What is SQL Injection?"

"Explain XSS like I'm a beginner."

"What's the difference between hashing and encryption?"

Instead of reading complicated documentation, you'll get explanations that match your experience level.

This makes learning much faster.

It Can Help You Build a Learning Roadmap

One of the hardest parts of cybersecurity isn't learning.

It's knowing what to learn next.

ChatGPT can create personalized learning paths such as:

Linux Basics
Networking Fundamentals
Python for Security
Web Security
OWASP Top 10
Wireshark
Nmap
Burp Suite
Active Directory
Cloud Security

Instead of jumping randomly between YouTube videos, you can follow a structured roadmap.

It Explains Complex Concepts Simply

Cybersecurity has lots of confusing terminology.

Terms like:

DNS Spoofing
Privilege Escalation
Buffer Overflow
Packet Sniffing
Reverse Shell

can sound intimidating.

ChatGPT can explain these concepts in plain English and even provide examples or analogies.

That makes difficult topics much easier to understand.

It Can Help You Practice

Learning theory is important.

Practice is even more important.

ChatGPT can generate:

Quiz questions
Interview questions
Scenario-based challenges
CTF-style exercises
Log analysis examples
Networking questions
Linux command practice

You can even ask:

"Pretend you're my interviewer."

"Give me beginner ethical hacking questions."

It's a great way to test your knowledge before an exam or interview.

It Can Help You Understand Security Tools

Many beginners struggle with tools like:

Nmap
Wireshark
Burp Suite
Metasploit
John the Ripper
Hashcat

ChatGPT can explain:

what each tool does,
when it's used,
common commands,
and what the output means.

That helps reduce the learning curve before you try the tools yourself.

Where ChatGPT Falls Short

This is the part many people ignore.

Cybersecurity is a practical field.

You cannot become a cybersecurity professional simply by chatting with an AI.

You still need hands-on experience.

For example:

Setting up virtual labs
Practicing Linux
Solving Capture The Flag (CTF) challenges
Working with vulnerable machines
Reading logs
Troubleshooting real issues
Learning from mistakes

ChatGPT can explain these activities—but it can't replace actually doing them.

AI Can Be Wrong

This is another important point.

ChatGPT sometimes provides:

outdated commands,
incorrect configurations,
incomplete explanations,
or simplified answers.

That's why you should always verify important information using official documentation or trusted cybersecurity resources.

Think of ChatGPT as a learning assistant—not the final authority.

The Best Way to Use ChatGPT

Here's a workflow that works well:

Learn the concept using ChatGPT.
Watch a demonstration if needed.
Practice in a virtual lab.
Read official documentation.
Build small projects.
Ask ChatGPT whenever you're stuck.

This combination helps you learn faster while building real-world skills.

Will AI Replace Cybersecurity Trainers?

Not anytime soon.

AI is excellent at explaining concepts and answering questions.

But mentors provide something AI cannot:

real-world experience,
practical troubleshooting,
career guidance,
feedback on mistakes,
and industry insights.

The strongest learners combine both AI tools and human mentorship.

Final Thoughts

ChatGPT has made cybersecurity learning more accessible than ever.

It can explain difficult concepts, generate study plans, answer questions, and help you practice.

But cybersecurity is ultimately a hands-on profession.

The real learning begins when you start building labs, solving problems, and experimenting in safe environments.

Use ChatGPT as a guide—not a shortcut.

Because in cybersecurity, experience is what truly builds confidence.

Thanks for reading!

How do you use ChatGPT while learning cybersecurity? Has it helped you understand difficult topics, or do you prefer traditional resources? Share your experience in the comments.

Can Someone Really Hack You Just by Knowing Your IP Address?

Qnayds Career — Mon, 03 Aug 2026 08:32:31 +0000

If you've ever played an online game, joined a Discord server, or streamed on Twitch, you've probably seen someone say:

"I know your IP address."

When I first saw that, I honestly thought:

"Well... that's it. My computer is probably hacked."

But after learning more about networking and cybersecurity, I realized the answer isn't nearly that simple.

## So... What Is an IP Address?

Think of an IP address like the mailing address for your internet connection.

When your device communicates with another server, it needs a way to send and receive data.

That's what an IP address is for.

Every website you visit sees your IP address.

Otherwise, it wouldn't know where to send the response.

So simply having your IP address isn't unusual.

## Can Someone Hack You With Only Your IP?

In most situations?

No.

An IP address alone doesn't magically give someone access to your computer.

Modern operating systems, home routers, NAT, and firewalls are designed to block unsolicited incoming traffic by default.

If your system is updated and properly configured, knowing your IP is usually not enough.

*## Then Why Do People Worry About It?
*
Because an IP address can still reveal some information.

Depending on your ISP and location, someone might estimate:

Your country
Your city or nearby region
Your Internet Service Provider (ISP)

Notice what isn't on that list:

❌ Your exact home address

❌ Your passwords

❌ Your photos

❌ Your files

Those aren't exposed just because someone knows your IP.

## When Does an IP Become a Problem?

Problems usually happen when an IP address is combined with something else.

For example:

A vulnerable device exposed to the internet
Poorly configured services
Weak router settings
Outdated software
Misconfigured remote access

In those situations, the IP simply helps someone locate the system.

The actual vulnerability is somewhere else.

## What About DDoS Attacks?

This is probably the biggest realistic risk.

If someone knows your public IP, they could attempt to overwhelm your internet connection with traffic.

This is called a Distributed Denial-of-Service (DDoS) attack.

It's less about stealing your data and more about making your connection temporarily unusable.

Fortunately, many ISPs and online services have protections against these attacks.

## Should You Hide Your IP?

For most people, there's no need to panic.

Instead, focus on the basics:

Keep your operating system updated.
Enable your firewall.
Secure your Wi-Fi with a strong password.
Don't expose unnecessary services to the internet.
Update your router firmware occasionally.
Be careful about downloading software from untrusted sources.

These habits reduce your risk far more than worrying about someone knowing your IP.

## The Bigger Cybersecurity Lesson

One thing I've learned is that cybersecurity myths spread much faster than cybersecurity facts.

Someone saying:

"I know your IP."

sounds scary.

But understanding what an IP address actually is removes a lot of unnecessary fear.

The same is true for many cybersecurity topics.

The more you understand how technology works, the harder it becomes for misinformation to scare you.

*## Final Thoughts
*
Cybersecurity isn't about being afraid of every technical term you hear.

It's about understanding the real risks.

So if someone tells you they know your IP address...

Don't panic.

Instead, ask yourself:

Is my system updated?

Is my router configured properly?

Am I exposing anything to the internet that shouldn't be?

Those questions matter much more than the IP address itself.

I'm curious:

What's the biggest cybersecurity myth you've heard that turned out to be completely false?

I Asked AI to Review My Code Security. Here's What It Got Wrong.

Qnayds Career — Sat, 01 Aug 2026 11:36:26 +0000

Like a lot of developers, I use AI almost every day now.

Need a regex? AI.

Need to understand an error? AI.

Need to write a quick API? AI.

Recently I wondered…

"Can AI review my code for security issues?"

So I gave it one of my small projects and asked it to point out potential vulnerabilities.

The result was interesting.

It Found Things I Missed

To be fair, AI wasn't useless.

It pointed out a few things that genuinely needed attention.

Hardcoded configuration values
Missing input validation
A couple of places where error messages revealed too much information
Some code that could be cleaned up

For a first review, that's actually impressive.

It was like having another developer quickly skim through the project.

But Then It Started Inventing Problems

This was the surprising part.

AI confidently told me one section of code was vulnerable to SQL injection.

The problem?

There wasn't even a database involved.

Another time it warned me about an authentication issue...

...inside a file that had absolutely nothing to do with authentication.

The explanations sounded convincing.

But once I actually checked the code, the "issues" simply weren't there.

That's when I realized something important.

AI isn't reviewing your application.

It's predicting what security issues are likely based on patterns it's seen before.

Sometimes that's incredibly useful.

Sometimes it's confidently wrong.

Security Needs Context

A human reviewer asks questions like:

What's this application actually supposed to do?
Who can access this endpoint?
Is this internal or public?
Where does this data come from?
What's the business risk if this fails?

AI doesn't always have that context.

It only knows what you've shown it.

That's a huge limitation.

It Missed One Thing I Expected It to Catch

This surprised me the most.

I had intentionally left a small authorization mistake in one route.

Nothing dramatic.

Just a missing permission check.

AI never mentioned it.

A human developer looking at the project probably would've asked:

"Wait… shouldn't this endpoint require authentication?"

That reminded me that security isn't just about spotting suspicious code.

It's about understanding how the entire application behaves.

So... Is AI Bad at Security?

Not at all.

I actually think it's one of the best productivity tools developers have.

I still use it to:

Explain unfamiliar code
Review functions
Suggest improvements
Generate tests
Summarize documentation
Brainstorm security ideas

But I no longer expect it to replace an actual security review.

What Changed for Me

Instead of asking:

"Is my code secure?"

I now ask AI much smaller questions.

For example:

"Can you review only the authentication logic?"
"Do you see any input validation issues here?"
"Could this endpoint expose sensitive information?"
"Is this SQL query safe?"
"Would this API design cause security problems?"

The answers became much more useful.

My Biggest Takeaway

AI is like having a very fast junior developer sitting next to you.

Sometimes it catches something you completely missed.

Sometimes it confidently suggests something that makes no sense.

Your job isn't to blindly accept every suggestion.

Your job is to understand why it's making that suggestion.

That's still where human experience matters.

Final Thoughts

I don't think AI is replacing secure coding anytime soon.

If anything, it's making developers even more responsible.

Because now we don't just review our own code.

We also have to review the code AI helps us write.

And honestly…

I think that's a skill every developer should start practicing now.

Have you ever asked AI to review your code?

Did it find a real issue—or did it confidently invent one?

You Don’t Need to Be a Hacker to Start Learning Cybersecurity

Qnayds Career — Fri, 31 Jul 2026 09:44:40 +0000

When I first became interested in cybersecurity, I thought I needed to know everything about hacking.

Kali Linux.
Nmap.
Metasploit.
Burp Suite.
Wireshark.

There seemed to be an endless list of tools to learn.

But after spending more time around cybersecurity, I realized something important:

Cybersecurity isn't really about knowing the most hacking tools. It's about understanding how technology works.

And that's actually good news for beginners.

Start With the Internet, Not Hacking Tools

Before trying to find vulnerabilities, understand what you're looking at.

What happens when you type a website address into your browser?

How does DNS work?

What is an IP address?

Why are there different ports?

What exactly happens when your browser sends an HTTP request?

These questions may sound basic, but they form the foundation of cybersecurity.

You don't need to know everything at once. Start with networking fundamentals and slowly connect the dots.

Linux Makes More Sense Once You Stop Memorizing Commands

Many beginners open Linux and immediately start memorizing commands.

I don't think that's the best approach.

Instead, understand what you're actually doing.

Learn about:

Files and directories
Users and permissions
Processes
Services
Networking
Shell commands
Basic Bash scripting

Once you understand the operating system, security tools become much easier to understand too.

Learn Some Programming

You don't need to become a full-time software developer before entering cybersecurity.

But knowing how code works is extremely useful.

Start with something simple like Python.

Learn variables, loops, functions, conditions, files, APIs, and basic scripting.

Later, you can explore JavaScript, SQL, Bash, or whatever fits your area of cybersecurity.

The goal isn't to become a programming expert.

It's to be able to look at code and understand what it's doing.

Learn How Websites Actually Work

If you're interested in ethical hacking, web security is difficult to avoid.

Learn the basics of:

HTTP and HTTPS
Cookies
Sessions
Authentication
APIs
Databases
Access control
Client-side vs server-side code

Once you understand these concepts, security vulnerabilities stop looking like random technical words.

You start understanding why they happen.

Build a Small Cybersecurity Lab

This is where learning becomes much more interesting.

Instead of only watching videos, create a safe environment where you can experiment.

For example, you can use virtual machines and intentionally vulnerable applications to practice.

You can also try CTF platforms and security labs designed for learning.

And one important rule:

Never test systems that you don't own or don't have explicit permission to test.

Ethical hacking is still hacking with boundaries.

AI Is Changing the Learning Process

Something else has changed for beginners today: AI.

You can ask an AI assistant to explain a networking concept in simple language.

You can ask it to explain an unfamiliar piece of code.

You can use it to brainstorm lab projects or help understand an error.

That's incredibly useful.

But there's a trap.

If you copy everything an AI gives you without understanding it, you may feel like you're learning while actually learning very little.

Use AI as a learning assistant, not as a replacement for thinking.

Try to understand the answer before moving on.

Don't Try to Learn Every Cybersecurity Field

Cybersecurity is massive.

You don't need to learn everything.

After getting comfortable with the basics, explore different areas.

Maybe you enjoy:

Ethical hacking — finding weaknesses.

SOC analysis — monitoring and investigating threats.

Cloud security — protecting cloud infrastructure.

Application security — securing software and web applications.

Digital forensics — investigating security incidents.

Incident response — dealing with attacks after they happen.

You don't have to decide your entire career on day one.

Explore first.

Your First Project Doesn't Have to Be Huge

A common mistake beginners make is waiting until they're "good enough" to build something.

Don't.

Build small projects.

For example:

Document your own cybersecurity lab
Analyze sample network traffic
Create a simple Python security utility
Write about a CTF challenge you solved
Practice identifying security issues in a deliberately vulnerable application
Create a basic security checklist for a small website

The project doesn't have to impress everyone.

It should show that you actually learned something.

The Biggest Skill Is Curiosity

Cybersecurity changes constantly.

New vulnerabilities appear.

New technologies are introduced.

Attackers change their techniques.

AI is changing both attacks and defense.

That means you can never really say:

"I've finished learning cybersecurity."

Instead, you need to become comfortable with learning continuously.

When something doesn't make sense, investigate it.

When a tool gives you an unexpected result, ask why.

When you see a security incident in the news, try to understand what actually happened.

That curiosity is more valuable than memorizing a hundred commands.

## Final Thought

If you're thinking about starting cybersecurity, don't wait until you have the perfect laptop, perfect certification, or perfect knowledge.

Start small.

Learn networking.

Understand Linux.

Learn basic programming.

Understand how websites work.

Practice safely.

Build projects.

And most importantly, keep asking why.

You don't need to become a hacker overnight.

You just need to become someone who understands technology well enough to recognize when something isn't right.

That's where a cybersecurity career can begin.