Security – User's blog

You have reached the end of this journey. You have learned the fundamentals of security, how to protect data, build secure infrastructure, and respond to threats.
This chapter brings everything together, showing how to keep a system in good condition over the long term – through monitoring, logging, incident response, and conscious management of the application lifecycle.
Because a good kitchen is not only about great recipes and tools – it is also about order, control, and vigilance every day.

Basic spices: Understanding the CIA Triad

The CIA Triad (Confidentiality, Integrity, Availability) is the foundation of the information security model and serves as a guide when creating policies and procedures in any organization. Just like basic spices in a kitchen, these three principles — confidentiality, integrity, and availability — must be properly balanced for a system to be both secure and usable.

Confidentiality – Protecting the secret recipe

Confidentiality: Ensures that sensitive data is protected from access by unauthorized individuals or systems. In the digital world, this means that only users with appropriate permissions can “see the recipe.”
Threats: Data may be stolen through direct attacks on systems, interception of communication (e.g., passwords or files), or as a result of human error, such as sending sensitive information to the wrong recipient.
Protection techniques: To preserve data privacy, encryption (both in transit and at rest), multi-factor authentication (MFA), strong passwords, and strict access control systems are used.

Integrity – Guarantee of accuracy and consistency

Integrity refers to the accuracy and completeness of data. It ensures that information has not been modified or tampered with by unauthorized parties, which can be compared to the certainty that no one has secretly changed the ingredients in your dish.
Threats: An attacker may attempt to alter the content of emails, modify configuration files, delete system logs, or inject malicious software into files.
Protection techniques: Integrity is verified using hashing, which creates a unique “digital fingerprint” of a file. Even the smallest change in the data results in a completely different hash, making tampering immediately detectable. Digital signatures, certificates, and change control processes are also used.

Availability – The kitchen always ready to serve

Availability means that authorized users have access to systems and data when they need them. Even the most secure system is useless if the chef cannot enter the kitchen and guests cannot place orders.
Threats: Availability can be affected by hardware failures, power outages, natural disasters, and cyberattacks such as DDoS (flooding a server with traffic to make it unavailable) or ransomware.
Protection techniques: To ensure continuity, backup power supplies (UPS), system redundancy, load balancing mechanisms, content delivery networks (CDN), and disaster recovery plans are used.

Why is the CIA Triad important?

Understanding these relationships allows developers to assess risk and prioritize actions. When analyzing each new application feature, it is worth asking: Can this data leak (confidentiality)? Can it be silently modified (integrity)? Can the system handle a sudden spike in traffic (availability)?

Preparing the workstation: Container and infrastructure security

In a professional kitchen, having a good recipe is not enough; you must ensure that your tools are clean and your workstation is safe. In the digital world, your “workstation” is the infrastructure where your code runs. We will now focus on how to ensure that this environment, most often based on containers, does not become the weakest link in your system.

Ingredient selection: Secure base images

Containerization has revolutionized application deployment, but it has also introduced new challenges. Every container image consists of multiple layers and libraries, each of which may contain “spoiled ingredients,” meaning security vulnerabilities.
Trusted sources: Always use official or verified images from trusted providers.
Minimalism (Distroless): Start with the smallest possible base image that contains only what is necessary for your application to run. The fewer tools in the container, the smaller the attack surface.
Image scanning: Regularly use tools such as Trivy or Docker Scout to detect known vulnerabilities before they reach production.

Clean countertops: Host hardening and kernel isolation

Containers share the host operating system kernel. If the kernel has a vulnerability, an attacker may “escape” from the container (container breakout) and take control of the entire server.
Dedicated hosts: Run containers on servers dedicated exclusively to this purpose to avoid conflicts with other applications.
Network isolation: By default, containers within the same network can communicate freely with each other. You should implement “segmentation,” meaning strict firewall rules that allow communication only between services that actually need it.

Secret storage: Secure secret management

One of the most common mistakes is leaving “keys in the door,” meaning hardcoding passwords or API keys directly in configuration files (e.g., Dockerfile).
Never hardcode secrets: Leaking an API key (e.g., to AWS) into a public repository can lead to massive financial losses within minutes.
Use dedicated tools: Use mechanisms such as Docker Secrets or external secret managers. These values should be injected into the container at runtime and encrypted.

Principle of least privilege: Who has access to the knives?

The Principle of Least Privilege states that every process and user should have access only to the resources necessary for their work. Think of it like working in a kitchen: a waiter does not need to carry a meat cleaver while serving dishes and taking orders.
Avoid root privileges: Containers should never run with administrator (root) privileges unless absolutely necessary.
Access control (RBAC): Implement roles and fine-grained permissions to limit an attacker’s ability to move within your system.

A menu full of traps: The most dangerous attacks and input validation

Even if your kitchen is sterile (secure containers) and the recipe is perfect, you can still poison your guests by using contaminated ingredients. In IT, those ingredients are user inputs. If you trust them blindly, you expose your system to the most serious vulnerabilities from the OWASP Top 10.

SQL Injection – Poisoning the database

This is one of the oldest and most dangerous “spices.” The attack occurs when an attacker sends malicious SQL commands instead of normal data (e.g., a login). If the application does not distinguish between code and data, the database will execute those commands, which may lead to the theft of millions of records, as in the case of Heartland Payment Systems.
Defense: Never concatenate strings manually when building queries. Use parameterized queries (Prepared Statements) or ORM tools that automatically separate code from input data.

Cross-Site Scripting (XSS) – Malicious scripts in the browser

An XSS attack involves injecting malicious JavaScript code into a page viewed by other users. The famous “Samy” worm in 2005 infected one million MySpace profiles in a single day. Such a script can steal session cookies, take over accounts, or perform actions on behalf of a logged-in user.
Defense: Apply strict server-side input validation (removing tags) and output encoding (for example converting < to <) so that the browser does not interpret data as code.

Cross-Site Request Forgery (CSRF) – Impersonating the chef

This attack tricks the browser of an authenticated user into performing an unwanted action on another site (e.g., changing a password or making a transfer), exploiting the fact that the site trusts the user’s session.
Defense: Use unique anti-CSRF tokens for each form and set the SameSite attribute on cookies to restrict their transmission in cross-site requests.

Golden rule: Never trust user input

The key to a safe “menu” is positive validation (allow-listing). Instead of trying to guess what might be dangerous, explicitly define what is allowed (e.g., only digits in an age field). Remember that validation must always be performed on the server side, as client-side protections (in the browser) are easy to bypass.

Secret recipes: The art of encryption and salting hashes

In every respectable kitchen, there are secrets that must not be revealed. Sometimes we need to send a recipe to another restaurant branch (encryption), and sometimes we only want to verify that a chef knows the secret password without revealing it to anyone (hashing). In this section, you will learn how to protect the confidentiality and integrity of your data.

Hashing – The digital fingerprint of ingredients

Hashing is a one-way process that transforms any amount of data into a fixed-length string. It can be compared to grinding meat – you can turn a piece of beef into mince, but you can never reconstruct the original piece of meat from it.
Use case: Ideal for storing passwords. The system does not need to know your password; it only stores its hash and compares it during login.
Algorithm choice: Avoid “outdated” algorithms such as MD5 or SHA-1, which are vulnerable to attacks. Use modern solutions like Argon2 or bcrypt.

Salt – Protection against “rainbow” attacks

Hashing alone is not enough. Attackers use so-called rainbow tables (precomputed lists of hashes for common passwords) to quickly break your security.
Salting technique: Before hashing, a salt (a unique, random string) is added to each password. This ensures that even identical passwords (e.g., “123456”) produce completely different hashes in the database, making large-scale attacks impractical.

Encryption – Indestructible safe

Unlike hashing, encryption is reversible, as long as you have the appropriate key.
Symmetric encryption: You use the same key to lock and unlock the safe (e.g., AES). It is fast, but you must securely share the key with the other party.
Asymmetric encryption: You have two keys – a public key (which anyone can use to “lock” a message for you) and a private key (which only you can use to “unlock” it). This is the foundation of secure communication on the internet.

HTTPS – Secure delivery of packages

Transmitting data over plain HTTP is like sending a package that any courier can open and read. HTTPS (HTTP + SSL/TLS) is like sending that same package inside an indestructible safe.
SSL/TLS: These protocols ensure that before data is transmitted, the server proves its identity using a certificate, and then both parties establish an encrypted communication channel.

Beware of JWT “hallucinations”

A common mistake is confusing encoding with encryption. JWT tokens, commonly used for authentication, are by default only encoded (Base64), not encrypted. This means that anyone can inspect their contents (e.g., user ID), although thanks to the digital signature, no one can silently modify them. Never store passwords or sensitive data in them.
Golden rule: Never create your own encryption algorithms (“Don’t roll your own crypto”). Use proven, standard libraries that have undergone rigorous security testing.

Guest selection: Authentication and session management

In every reputable restaurant, controlling who enters and who has access to the kitchen versus the dining area is essential. In system security, this process is divided into two fundamental stages: authentication (verifying identity) and authorization (verifying permissions).

Who is knocking at the door? Authentication

Authentication is the process of verifying a user’s identity — the system must be sure that the “guest” is who they claim to be.
Traditional methods: These include passwords, PIN codes, or biometrics. Increasingly, multi-factor authentication (MFA) is recommended, as it protects against credential theft.

Sessions vs Tokens

Traditional sessions store state on the server (e.g., in a database), which makes them easier to invalidate but harder to scale. Modern API systems more often use tokens (e.g., JWT), which are stateless the server does not need to “remember” them because all necessary user information is contained within the token itself.

Access management best practices: The code pantry

Short lifespan: Tokens should expire quickly to limit the time window for a potential attacker.

Refresh tokens: Allow generating new tokens without requiring the user to re-enter their password.

Ownership verification: It is not enough to check whether a user is authenticated; you must always verify that they own the resource they are requesting (e.g., “is this my invoice?”).

Serving dishes: Secure APIs and protection against overload

An API (Application Programming Interface) acts like a serving window or a waiter in your restaurant — it mediates communication between systems, passing requests from the client (frontend) to the kitchen (backend). Because APIs are exposed to the outside world, they are a primary target for attacks, which requires strong security mechanisms.

Crowd control: Rate limiting mechanisms

Even if your system is secure, it may stop working if it is overwhelmed by too many requests at once (DDoS attacks or client-side application errors). Rate limiting is the practice of restricting the number of requests a given user or IP address can make within a specific time frame.
Strategies: You can use fixed limits (e.g., 100 requests per minute), dynamic limits (depending on system load), or advanced algorithms such as token bucket or leaky bucket, which allow short bursts of requests while maintaining server stability.
Benefit: Rate limiting protects against abuse, optimizes resource usage, and provides time to respond to brute-force attacks on API keys.

Maître d’ system: API Gateway

Instead of implementing security measures in each microservice individually, it is worth using an API Gateway — a central entry point to the system.
The gateway acts like a restaurant manager: it handles authentication, enforces rate limiting, manages traffic logging, and can route requests to the appropriate services.
This makes the architecture simpler and ensures that security policies are enforced in a single, easily monitored place.

Secure error handling

The way your API communicates errors is critical for security. Never return full stack traces or detailed database errors in a production environment.

Bad response: “SQL error on line 45: table ‘Users’ does not contain column ‘credit_card’” — this is a ready-made map for an attacker.
Good response: “Invalid input data. Please check the parameters and try again.”
Principle: The message should be helpful for a legitimate developer but useless to an attacker, without revealing technical details about the infrastructure.

Cleaning up after the feast: Monitoring, logging, and the application lifecycle

The final stage of work in a professional kitchen involves maintaining order, checking product expiration dates, and ensuring that no unauthorized person is lingering around the pantry after closing. In software engineering, this corresponds to system monitoring, event logging, and maintaining regular updates, which helps preserve the “health” of the application over time.

Digital breadcrumbs: Why logging is more than just debugging

Many developers believe that logs are used only for fixing errors, but in reality, they are “breadcrumbs” that allow you to trace an intruder’s actions. Without proper logging, you may learn about a breach with significant delay — real-world cases show that data leaks have gone unnoticed for up to seven years without monitoring.

What to log? Focus on failed login attempts, permission changes, server-side validation errors, and access to particularly sensitive endpoints.
Best practices: Logs should be readable, standardized, and stored in a way that prevents easy tampering by an attacker trying to cover their tracks.

Chef’s vigilance: Monitoring and real-time alerting

Recording events alone is not enough — you need to know when something unusual is happening in your system. Monitoring systems help detect anomalies before they escalate into serious incidents.
Intrusion detection: Tools such as IDS (Intrusion Detection System) analyze network traffic and system calls, notifying you of suspicious activity.
Availability: Monitoring also allows you to quickly respond to DDoS attacks, which involve flooding a server with traffic to make it unavailable. With cloud scaling and proper alerting, you can keep the system “online” even under heavy load.

Emergency plan: What to do when the dish gets burned? (Incident Response)

Even the best security measures can fail, which is why you need an Incident Response Plan (IRP). Knowing how to act when a breach is detected reduces response time and minimizes losses.
Isolation: The first step after detecting a breach should be to isolate affected systems or containers to prevent the attack from spreading.
Remediation and recovery: Once the situation is under control, the root cause must be identified, malicious code removed, and the system rebuilt from secure, “clean” images.

Security as a process: SDLC and Secure by Design

Security is not an “add-on” applied to an application at the very end. It should be an integral part of the entire software development lifecycle (SDLC). The Secure by Design approach assumes that data protection is considered already at the planning stage, by introducing secure default configurations and automating security controls at every step.

Summary

The software development process is a multi-stage journey that begins with identifying a real problem (Problem Discovery) and ends with delivering a secure and scalable product. The key to success is not just writing code, but adopting a “Secure by Design” approach, which assumes that security is an integral part of every stage — from planning, through architecture, to system maintenance. Security in IT is not a one-time event, but a continuous process of improvement.

PS. Your Digital Cookbook: Congratulations! You now have a complete set of proven recipes, techniques, and engineering best practices in your hands. You possess all the knowledge necessary to independently create your own professional cookbook. From the foundations of architecture, through frontend and backend development, to deployment and security. You have become the chef of your own code, and once again, congratulations 👏. See you in future articles, where perhaps I will learn something from you.

Materials

Self-study materials that are related to this topic: