Security in Norwegian web applications — what GDPR and the Personal Data Act actually require
Many Norwegian businesses underestimate the security requirements for web applications. Here we walk through what the law actually demands, common mistakes we see, and concrete measures you can implement today.
In 2024, the Norwegian Data Protection Authority (Datatilsynet) received 2,527 breach notifications — a 12% increase from the previous year. Many of these stemmed from basic web application deficiencies: missing encryption, weak authentication solutions, and absence of access control.
Web application security isn't just about technology. It's about meeting legal requirements, protecting customer trust, and avoiding fines that can reach 20 million euros or 4% of global turnover under GDPR.
This article provides a practical walkthrough of what Norwegian businesses actually need to do — with concrete measures you can implement.
What do GDPR and the law require of your web application?
The Personal Data Act and GDPR
Norway's Personal Data Act (personopplysningsloven) implements the EU's General Data Protection Regulation (GDPR) in Norwegian law. For web applications processing personal data, these articles are most relevant:
| GDPR Article | Requirement | Practical consequence for web apps |
|---|---|---|
| Art. 5(1)(f) | Integrity and confidentiality | Data must be protected against unauthorized access and loss |
| Art. 25 | Data protection by design | Security must be built in from the start, not added later |
| Art. 32 | Security of processing | Encryption, pseudonymization, and regular testing |
| Art. 33–34 | Breach notification | Breaches must be reported to Datatilsynet within 72 hours |
| Art. 35 | DPIA (Data Protection Impact Assessment) | Required for high-risk processing |
The Electronic Communications Act § 2-7 b
For websites using cookies or similar tracking, Norway's Electronic Communications Act (ekomloven) requires informed consent. Exceptions apply only to technically necessary cookies.
What are the most common security mistakes in Norwegian web applications?
Through our work with technical consulting and code reviews, we see the same mistakes repeatedly:
1. Missing Content Security Policy (CSP)
CSP is an HTTP header that tells the browser which sources are allowed to execute scripts, load images, and connect to other servers. Without CSP, the application is vulnerable to cross-site scripting (XSS) — the most common attack vector according to the OWASP Top 10.
Action: Define a strict CSP that only allows known sources. Start with default-src 'self' and add exceptions as needed.
2. Absence of HSTS
HTTP Strict Transport Security (HSTS) forces the browser to always use HTTPS. Without this, an attacker can perform a "downgrade attack" redirecting traffic to unencrypted HTTP.
Action: Add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload to HTTP headers.
3. Weak authentication
Home-built login solutions with plaintext passwords, missing rate limiting, or absence of two-factor authentication (2FA) remain surprisingly common — even in 2026.
Action: Use established authentication frameworks like NextAuth, Auth0, or Microsoft Entra ID. Implement 2FA for admin access. We use Microsoft Entra ID across all our projects for exactly this reason.
4. Missing input validation
All user input — form fields, URL parameters, file uploads — must be validated and sanitized server-side. Client-side validation is useful for user experience but provides zero security.
Action: Validate all input with a strict schema (e.g., Zod or Joi). Sanitize HTML content through an allowlist, never a blocklist.
5. Exposed error messages
Stack traces and detailed error messages in production give attackers valuable information about your technology stack, file paths, and database structure.
Action: Return generic error messages to users. Log detailed errors internally.
6. Outdated dependencies
Known vulnerabilities in npm packages are one of the easiest attack vectors. According to the Snyk State of Open Source Security Report 2024, 84% of all JavaScript projects had at least one known vulnerability in their dependency tree.
Action: Run npm audit regularly. Use Dependabot or Snyk for automated alerts.
7. Missing logging and monitoring
Without logging, you don't know you've been attacked. GDPR Article 33 requires breaches to be reported within 72 hours — that assumes you actually detect the breach.
Action: Log authentication events, authorization failures, and unusual patterns. Set up alerts for anomalies.
Security measures in practice: our approach
At UNOS SOFTWARE AS, we treat security as a pervasive principle, not a layer added on top of a finished application. Here are the concrete measures we implement in every project:
Transport layer
- HTTPS with HSTS preload — all traffic is encrypted, and the browser remembers to always use HTTPS
- TLS 1.3 — latest encryption protocol with improved performance and security
Application layer
- Content Security Policy — strictly defined allowlist for scripts, styles, and connections
- Input validation — all user input is validated server-side with Zod schemas
- Content sanitization — markdown and HTML are sanitized through a strict allowlist using sanitize-html
- JWT-based authentication — session management without server state, with short expiration times
Infrastructure layer
- Azure Key Vault — secrets are never stored in code or plaintext environment variables
- Role-based access control (RBAC) — users get access only to what they need
- Data center in Norway — Azure Norway East for compliance with the Personal Data Act
Read more about how we set up secure infrastructure in our cloud and infrastructure service.
OWASP Top 10: a checklist
OWASP (Open Worldwide Application Security Project) regularly publishes a list of the ten most critical security risks for web applications. Here is the current list with practical measures:
| # | Risk | Measure |
|---|---|---|
| 1 | Broken Access Control | RBAC, server-side checks on all endpoints |
| 2 | Cryptographic Failures | TLS 1.3, AES-256 for data at rest |
| 3 | Injection | Parameterized queries, input validation |
| 4 | Insecure Design | Threat modeling, security reviews in design phase |
| 5 | Security Misconfiguration | Strict CSP, disable unnecessary features |
| 6 | Vulnerable Components | Automated dependency checking, regular updates |
| 7 | Auth Failures | Established auth frameworks, 2FA, rate limiting |
| 8 | Data Integrity Failures | Signed updates, integrity checks |
| 9 | Logging Failures | Structured logging, anomaly detection |
| 10 | SSRF | Validation of server-side requests, network isolation |
Datatilsynet's expectations
The Norwegian Data Protection Authority has intensified its oversight of web applications in recent years. In several rulings, they have noted that:
- Encryption of personal data in transit and at rest is a minimum requirement, not a bonus
- "Privacy by design" (GDPR Art. 25) means security must be considered before development begins
- Businesses are responsible for security in third-party systems they use as well
For businesses processing health records, financial data, or large volumes of personal data, Datatilsynet recommends conducting a DPIA (Data Protection Impact Assessment) before launch.
What you should do now
If you're uncertain about the security level of your web application, we recommend starting with these three steps:
- Run a security review — we offer technical consulting focused on security, including code review and OWASP checks
- Update your infrastructure — ensure HTTPS, CSP, and HSTS are in place. Move secrets out of code
- Establish routines — automate dependency checks, set up logging, and create a plan for breach management
Need help securing your web application? Get in touch for a free consultation about the security level of your solutions.
Sources and further reading
- Datatilsynet (2025). Annual Report 2024 — breach notifications and oversight statistics. datatilsynet.no
- OWASP Foundation (2025). "OWASP Top 10 Web Application Security Risks." owasp.org
- Snyk (2024). "State of Open Source Security Report 2024." snyk.io
- Lovdata (2018). Act relating to the processing of personal data (Personal Data Act). lovdata.no
- EUR-Lex (2016). Regulation (EU) 2016/679 (GDPR). eur-lex.europa.eu
- Lovdata (2003). Act relating to electronic communications (Electronic Communications Act). lovdata.no