<\/span><\/h2>\n\n\n\nAuthentication and authorization are the most exposed element of web application security. Which strategy should you choose? It depends on the project. OAuth 2.0 works great when you need to integrate with external identity providers. Server-side sessions offer simplicity and full control in closed B2B systems. And JWT (JSON Web Tokens)? Hugely popular in microservice architectures, but they carry real risks. A token signed with a weak algorithm or kept in localStorage is a gift to attackers exploiting XSS. At Web Systems we pick the strategy case by case – we analyze the business requirements, the scale of the system and the threat profile.<\/p>\n\n\n\n
Multi-factor authentication (MFA) should be the standard. Especially in systems processing sensitive or financial data. The cost of implementing TOTP (Time-based One-Time Password) or integrating with authenticator apps? Marginal compared with the risk of account takeover through phishing or credential stuffing. In our B2B projects MFA is a default requirement for administrative accounts. We increasingly roll it out for end users too – progressively. The system asks for a second factor during higher-risk operations, not at every login.<\/p>\n\n\n\n
The permission model? It depends on the complexity of the client’s organizational structure. RBAC (Role-Based Access Control) is enough when you have a fixed, small number of roles – administrator, moderator, user. But in complex systems where permissions depend on the department, location, time of access or document classification, ABAC (Attribute-Based Access Control) gives you far more flexibility. Tip:<\/strong> In SPA applications store access tokens in memory (a JavaScript variable) and refresh tokens in HttpOnly cookies with the Secure and SameSite flags. Avoid localStorage – it is available to every script on the page. With an XSS vulnerability that means an immediate takeover of the user’s session.<\/p>\n\n\n\n<\/span>Data protection and GDPR compliance in web applications<\/span><\/h2>\n\n\n\nProtecting personal data is not just a tick in the “GDPR compliant” checkbox. It is a matter of trust from customers and partners. The foundation? Encryption on two levels. Data in transit – TLS 1.3 (we disable older versions of the protocol). Data at rest – encryption at the database or file system level. We store user passwords exclusively as hashes generated with brute-force resistant algorithms – bcrypt or Argon2id with a properly chosen computational cost. MD5? SHA-256 for passwords? Never. Their computational speed works in the attackers’ favor.<\/p>\n\n\n\n
Privacy by design means designing GDPR-compliant systems from the first architecture sketch, not patching an existing system after the fact. What does that look like in our practice? Minimizing the data we collect (we ask ourselves: do we really need this information?), pseudonymization wherever possible, separating identifying data from analytical data. Every operation on personal data is recorded in an immutable audit log – who did what and when. Such a log helps detect unauthorized access and prove compliance during an inspection by the supervisory authority.<\/p>\n\n\n\n
The right to erasure (Article 17 GDPR) is a real challenge in complex B2B systems. A customer’s personal data spreads across many tables, services and backups. Complete removal requires a well thought out strategy. We use a soft delete pattern with cascading anonymization – instead of physically deleting records we replace identifying data with irreversible values. We keep the referential integrity of the database and the ability to process aggregated data. We define the retention policy together with the client, and we automate the deletion process itself once the storage period expires. Because nobody can handle that manually.<\/p>\n\n\n\n