Summary
The socialSecurityNumber (personnummer) field is currently rendered unconditionally for all logged-in roles on the Employment page (/pages/employment.html), even though the PR objective states that all roles can view the employee list. This exposes sensitive PII to roles that have no business need for it.
Issues to address
1. Role-gated frontend rendering
In src/main/resources/static/js/employment.js, the personnummer is rendered in the employee card without any role check:
<p><strong>Personnummer:</strong> ${escapeHtml(staff.socialSecurityNumber || -)}</p>
This should only be displayed to users with HR or ADMIN roles, using the existing employmentCurrentUser variable, e.g.:
${(employmentCurrentUser?.role === HR || employmentCurrentUser?.role === ADMIN)
? `<p><strong>Personnummer:</strong> ${escapeHtml(staff.socialSecurityNumber || -)}</p>`
: }
2. Backend field filtering / encryption
Beyond frontend guards, socialSecurityNumber should either be excluded from the /staff API response for non-HR/ADMIN roles, or encrypted at rest in the database and masked in transit for unauthorized roles.
References
Requested by @codebyNorthsteep
Summary
The
socialSecurityNumber(personnummer) field is currently rendered unconditionally for all logged-in roles on the Employment page (/pages/employment.html), even though the PR objective states that all roles can view the employee list. This exposes sensitive PII to roles that have no business need for it.Issues to address
1. Role-gated frontend rendering
In
src/main/resources/static/js/employment.js, the personnummer is rendered in the employee card without any role check:This should only be displayed to users with HR or ADMIN roles, using the existing
employmentCurrentUservariable, e.g.:2. Backend field filtering / encryption
Beyond frontend guards,
socialSecurityNumbershould either be excluded from the/staffAPI response for non-HR/ADMIN roles, or encrypted at rest in the database and masked in transit for unauthorized roles.References
Requested by @codebyNorthsteep