Giters
kyrcha
/
secure-mern-app
A secure web application using the MERN stack
Geek Repo:
Geek Repo
Github PK Tool:
Github PK Tool
Stargazers:
3
Watchers:
2
Issues:
133
Forks:
1
kyrcha/secure-mern-app Issues
4.3.3 Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.
Updated
4 years ago
4.3.2 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
Updated
4 years ago
4.3.1 Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.
Updated
4 years ago
4.2.2 Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.
Updated
4 years ago
4.2.1 Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
Updated
4 years ago
4.1.5 Verify that access controls fail securely including when an exception occurs.
Updated
4 years ago
4.1.4 Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.
Updated
4 years ago
4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
Updated
4 years ago
4.1.2 Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
Updated
4 years ago
4.1.1 Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
Updated
4 years ago
3.7.1 Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.
Updated
4 years ago
3.6.2 Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.
Updated
4 years ago
3.6.1 Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a session within that period.
Updated
4 years ago
3.5.3 Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.
Updated
4 years ago
3.5.2 Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.
Updated
4 years ago
3.5.1 Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to terminate trust relationships with linked applications.
Updated
4 years ago
3.4.5 Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible.
Updated
4 years ago
3.4.4 Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality.
Updated
4 years ago
3.4.3 Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.
Updated
4 years ago
3.4.2 Verify that cookie-based session tokens have the 'HttpOnly' attribute set.
Updated
4 years ago
3.4.1 Verify that cookie-based session tokens have the 'Secure' attribute set.
Updated
4 years ago
3.3.4 Verify that users are able to view and log out of any or all currently active sessions and devices.
Updated
4 years ago
3.3.3 Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties.
Updated
4 years ago
3.3.2 If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.
Updated
4 years ago
3.3.1 Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
Updated
4 years ago
3.2.4 Verify that session token are generated using approved cryptographic algorithms
Updated
4 years ago
3.2.3 Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
Updated
4 years ago
3.2.2 Verify that session tokens possess at least 64 bits of entropy
Updated
4 years ago
3.2.1 Verify the application generates a new session token on user authentication.
Updated
4 years ago
3.1.1 Verify the application never reveals session tokens in URL parameters or error messages.
Updated
4 years ago
2.10.4 Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories.
Updated
4 years ago
2.10.3 Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.
Updated
4 years ago
2.10.2 Verify that if passwords are required, the credentials are not a default account.
Updated
4 years ago
2.10.1 Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.
Updated
4 years ago
2.9.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
Updated
4 years ago
2.9.2 Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
Updated
4 years ago
2.9.1 Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage.
Updated
4 years ago
2.8.7 Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.
Updated
4 years ago
2.8.6 Verify physical single factor OTP generator can be revoked in case of theft or other loss
Updated
4 years ago
2.8.5 Verify that if a time-based multi factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.
Updated
4 years ago
2.8.4 Verify that time-based OTP can be used only once within the validity period.
Updated
4 years ago
2.8.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
Updated
4 years ago
2.8.2 Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.
Updated
4 years ago
2.8.1 Verify that time-based OTPs have a defined lifetime before expiring.
Updated
4 years ago
2.7.6 Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).
Updated
4 years ago
2.7.5 Verify that the out of band verifier retains only a hashed version of the authentication code.
Updated
4 years ago
2.7.4 Verify that the out of band authenticator and verifier communicates over a secure independent channel.
Updated
4 years ago
2.7.3 Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.
Updated
4 years ago
2.7.2 Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.
Updated
4 years ago
2.7.1 Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.
Updated
4 years ago
Previous
Next