POC Control

Requirements:: Password Security
Control Name: Verify that user set passwords are at least 12 characters in length (after
multiple spaces are combined).
How to Validate: Use tools like Burp Suite or OWASP ZAP to intercept network traffic and
examine the request/response payloads to see how the password is being transmitted and
processed.
POC:
Here we can see that the HTTP response code is 302. That required the client to perform a
temporary redirect with the same method along with means redirects by changing the method to
GET. There is no password length policy. So, we can say that the minimum password length
isn’t 12.
Control Name: Verify that passwords of at least 64 characters are permitted, and that
passwords of more than 128 characters are denied.
processed.
POC:
It accepts passwords whose lengths are more than or equal to 64.
It accepts passwords whose lengths are less than or equal to 127 and denied more than or
equal to 128.
Password length 127(request)
Password length 127(response)
So, the website accepts passwords whose lengths are less than or equal to 64 and denies
passwords more than or equal to 128.
Control Name: Verify that password truncation is not performed. However, consecutive
multiple spaces may be replaced by a single space.
processed.
POC:
It counts all spaces. That means consecutive multiple spaces are not replaced by a single
space.
Control Name: Verify that any printable Unicode character, including language neutral
characters such as spaces and Emojis are permitted in passwords.
processed.
POC:
There are no responses. So, it doesn’t accept all printable unicode.

Requirements: General Authenticator Security
Control Name: Verify that anti-automation controls are effective at mitigating breached
credential testing, brute force, and account lockout attacks. Such controls include blocking the
most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing
delays between attempts, IP address restrictions, or risk-based restrictions such as location,
first login on a device, recent attempts to unlock the account, or similar. Verify that no more than
100 failed attempts per hour is possible on a single account.
How to Validate: Try to perform a brute force attack by continuously entering incorrect
passwords. Observing the behavior of the system, if it blocks the IP address, increases the
delay between attempts, or imposes a lockout after a certain number of failed attempts, it
indicates that the anti-automation controls are working as expected.
POC:
It doesn’t block the failed attempts as the response code isn’t 404. So, it breaks
the control.
Control Name: Verify that the use of weak authenticators (such as SMS and email) is limited
to secondary verification and transaction approval and not as a replacement for more secure
authentication methods. Verify that stronger methods are offered before weak methods, users
are aware of the risks, or that proper measures are in place to limit the risks of account
compromise.
How to Validate: Try to make more than 100 failed attempts in an hour on a single account
and observe if the system blocks the IP address or imposes a lockout. If the system allows more
than 100 failed attempts, it indicates that the anti-automation controls need to be tightened.
POC:
It doesn’t block the failed attempts as the response code isn’t 404. So, it breaks
the control.
Requirements:: Fundamental Session Management Security
Control Name: Verify the application never reveals session tokens in URL parameters.
How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp Suite to
monitor the network traffic between the client and the server. Attempt to authenticate to the
application using valid credentials.
POC:
It doesn’t reveal session tokens.

Requirements: Session Binding
Control Name: Verify the application generates a new session token on user authentication.
How to Validate: Check the server's response that the server responds with a new session
token after successful authentication by Wireshark or Burp suite. The session token should be
unique and not easily guessable.
POC:
Tokens and cookies are the same for two times of login. So, it breaks “Session Management”.
Control Name: Verify that session tokens possess at least 64 bits of entropy.
POC:
Tokens are 50 bits here that don't follow the 64 bits control.
Control Name: Verify the application only stores session tokens in the browser using secure
methods such as appropriately secured cookies or HTML 5 session storage.
How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp Suite or
Inspect to monitor the network traffic between the client and the server. Attempt to authenticate
to the application using valid credentials.
POC:
No local storage and session storage.

Control Name: Verify that session tokens are generated using approved cryptographic
algorithms.
POC:
Requirements: Session Termination
Control Name: 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.
How to Validate: Log out of the application and log back in to see if a new session token is
generated each time.
POC:
After logout from the site, I clicked the back button and then reloaded the site and
captured the burp request. After forwarding some requests, I get back the uname
and password. By forwarding it, I get access to the site.
So, it violates the logout control.
Control Name: If authenticators permit users to remain logged in, verify that re-
authentication occurs periodically both when actively used or after an idle period.
How to Validate: Use Burp Suite to see the request token of logging in.
POC:
No re-authentication occurs. So, it breaks the control.

Control Name: Verify that the application gives the option to terminate all other active
sessions after a successful password change (including change via password reset/recovery),
and that this is effective across the application, federated login (if present), and any relying
parties.
How to Validate: Use Burp Suite to see the response.
POC:
After changing, no alert happened.
Control Name: Verify that users are able to view and (having re-entered login credentials)
log out of any or all currently active sessions and devices.
How to Validate: Use Burp Suite to see the response and request.
POC:
Decoded cookie as URL.

Requirements: Cookie-based Session Management
Control Name: Verify that cookie-based session tokens have the 'Secure' attribute set.
How to Validate: Use Burp Suite or Inspect option to navigate to the "Application" or
"Storage" tab in the developer tools. Find the section for Cookies and select the website you
want to inspect. Look for the cookie that represents the session token and examine its
attributes. Verify that the 'Secure' attribute is set to 'True'. This means that the cookie will only
be transmitted over an encrypted connection (HTTPS) and will not be sent over an unencrypted
connection (HTTP). If the 'Secure' attribute is not set, this means that the session token could
be intercepted by an attacker and used to hijack the user's session.
POC:
Secure attribute isn’t set.

Control Name: Verify that cookie-based session tokens have the 'HttpOnly' attribute set.
How to Validate: Use Burp Suite or Inspect option to navigate to the "Application" or
"Storage" tab in the developer tools. Find the section for Cookies and select the website you
want to inspect. Look for the cookie that represents the session token and examine its
attributes. Verify that the 'HTTP Only' attribute is set to 'True'. This means that the cookie will
only be transmitted over an encrypted connection (HTTPS) and will not be sent over an
unencrypted connection (HTTP). If the 'Secure' attribute is not set, this means that the session
token could be intercepted by an attacker and used to hijack the user's session.
POC:
HttpOnly isn’t set.

Control Name: Verify that cookie-based session tokens utilize the 'SameSite' attribute to
limit exposure to cross-site request forgery attacks.
How to Validate: Inspect the request and see the cookie-session.
POC:
The SameSite attribute isn’t set.

Control Name: Verify that cookie-based session tokens use the "__Host-" prefix so cookies
are only sent to the host that initially set the cookie.
POC:
There is no HOST prefix in this site.

Control Name: Verify that if the application is published under a domain name with other
applications that set or use session cookies that might disclose the session cookies, set the
path attribute in cookie-based session tokens using the most precise path possible.
POC:
Path isn’t set as precise.

Requirements: Token-based Session Management
Control Name: Verify the application allows users to revoke OAuth tokens that form trust
relationships with linked applications.
How to Validate: Use Burp Suite to see the session token generation using the Burp
Intruder, Sequencer and Decoder tools.
POC:
A general cookie setter.

Control Name: Verify the application uses session tokens rather than static API secrets and
keys, except with legacy implementations.
How to Validate: Use Inspect to see the cookie.
POC:
It uses a static cookie named “login=test%2Ftest”.

Control Name: Verify that stateless session tokens use digital signatures, encryption, and
other countermeasures to protect against tampering, enveloping, replay, null cipher, and key
substitution attacks.
How to Validate: Use Inspect to see the cookie generation.
POC:
Always set as 3 which breaks the control.

Requirements: Federated Re-authentication
Control Name: Verify that Relying Parties (RPs) specify the maximum authentication time to
Credential Service Providers (CSPs) and that CSPs re- authenticate the user if they haven't
used a session within that period.
How to Validate: Make sure that the maximum authentication time is specified in a secure
manner. Conduct a test to see how the authentication process works between RPs and CSPs.
Try to access a resource that requires authentication and observe how the system behaves.
Make sure that the re-authentication process is secure and that the user's credentials are
encrypted when transmitted. Check that the system logs the re-authentication events properly.
This will help the application owner to track when re-authentication occurs and to identify any
potential issues. Finally, we have to test the system for security vulnerabilities related to
authentication. For example, trying to bypass the authentication process or manipulate the
maximum authentication time to see if we can access a resource without proper authentication.
POC:
and password. By forwarding it, I get access to the site. It doesn’t need any re-
authentication.
Control Name: Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs)
of the last authentication event, to allow RPs to determine if they need to re-authenticate the
user.
How to Validate: Starting by understanding how the authentication process works between
RPs and CSPs. Get a clear understanding of the flow of data between the two parties. Next, we
have to review the source code of the RPs and CSPs to look for any references to a maximum
authentication time. Make sure that the maximum authentication time is specified in a secure
manner.
POC:
Requirements: Defenses Against Session Management Exploits
Control Name: Verify the application ensures a full, valid login session or requires re-
authentication or secondary verification before allowing any sensitive transactions or account
modifications.
How to Validate: Try to log in to the application using valid credentials and observe how the
application handles the login process. Check if the application implements proper authentication
methods, such as password hashing and salting, to secure the user's login information. Make
sure that the application generates a new session ID for each login and that it's properly tied to
the user's account.
POC:
It doesn’t generate different cookies.
Requirements:: General Access Control Design
Control Name 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.
Control Name 2: Verify that all user and data attributes and policy information used by
access controls cannot be manipulated by end users unless specifically authorized.
Control Name 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.
Control Name 4: Verify that access controls fail securely including when an exception
occurs.
How to Validate: Start by testing the client-side access controls to see if they can be
bypassed. This can be done by modifying the client-side code or intercepting the client-side
communication to see if the access control rules can be circumvented. After testing the client-
side access controls, test the server-side access controls to ensure that they are being enforced
as expected. This can be done by sending specially crafted requests to the server to see if the
access control rules are being applied correctly. Attempt to access resources and perform
actions that should not be allowed according to the access control rules. This can help verify
that the access control rules are being properly enforced and that there are no gaps or
weaknesses in the implementation. Ensure that the trusted service layer is properly secured and
that it is enforcing the access control rules as expected. This could include verifying that the
service layer is using encryption and that it is properly authenticating requests.
POC:
Without login, it doesn’t give any access to the site to change anything. But we
can bypass the request using sql injections that are vulnerable to malicious code.
Requirements: Operation Level Access Control
Control Name 1: Verify that sensitive data and APIs are protected against Insecure Direct
Object Reference (IDOR) 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.
Control Name 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.
How to Validate: Test the creation, reading, updating, and deletion of records in the system
to identify any IDOR vulnerabilities. This could include trying to create or update records for
other users, viewing records for all users, or deleting all records. Check for direct object
references in the system, such as URLs or parameters that reference a specific record or
object. Direct object references can make it easier for an attacker to manipulate the data or
perform unauthorized actions. Ensure that access controls are in place to prevent unauthorized
access to sensitive data and APIs. This could include authentication, authorization, and
encryption. The access control logic is properly implemented and that it is not broken. This
could include checking for missing or incorrect access control checks, or checking that the
access control rules are properly enforced on the server side. Monitor logs and audit trails for
unusual or suspicious activity, such as repeated attempts to access sensitive data or perform
unauthorized actions. This can help detect and prevent IDOR attacks.
POC:
Its attributes aren’t set properly, that's why it is vulnerable to IDOR attacks.
Requirements: Other Access Control Considerations
Control Name 1: Verify administrative interfaces use appropriate multi-factor authentication

to prevent unauthorized use.
Control Name 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.
Control Name 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.
How to Validate: Start by testing the authentication mechanism used by the administrative
interface to ensure that it is properly implemented and secure. This could include attempting to
bypass the authentication mechanism, or testing the strength of the passwords used. Ensure
that the administrative interface uses multi-factor authentication, such as something the user
knows (a password), something the user has (a smart card or token), and something the user
has (biometrics). Check for implementation weaknesses in the multi-factor authentication
mechanism, such as missing or weak security controls, or the use of easily guessable or easily
obtainable authentication factors. Test the authentication process to ensure that it is working
correctly and that the multi-factor authentication is being used properly. This could include
attempting to log in with different combinations of authentication factors. Monitor logs and audit
trails for unusual or suspicious activity, such as repeated attempts to log in or access the
administrative interface. This can help detect and prevent unauthorized access.
POC:
When I tried to login manually to this site, there were no two factor authentication
systems implemented.
Requirements:: Input Validation
Control Name: Verify that the application has defenses against HTTP parameter pollution
attacks, particularly if the application framework makes no distinction about the source of
request parameters (GET, POST, cookies, headers, or environment variables).
How to Validate: For manual testing, try to inject multiple parameters with the same name,
and observe the application's behavior. Also can use tools like Burp Suite or OWASP ZAP to
modify the parameters in a request and observe the response from the application. If the
application is vulnerable, it will likely use only the last parameter provided, or concatenate the
values of all parameters with the same name. Use a web application vulnerability scanner to
identify any potential HPP vulnerabilities. Some scanners, such as OWASP ZAP, can
automatically detect HPP vulnerabilities and provide recommendations for remediation. Conduct
a penetration test to see if an attacker can exploit HPP vulnerabilities in the application. This
can be done manually or with automated tools.
POC:
Request-1
Request-2
Different behavior on different requests.

Control Name 1: Verify that frameworks protect against mass parameter assignment
attacks, or that the application has countermeasures to protect against unsafe parameter
assignment, such as marking fields private or similar.
Control Name 2: Verify that all input (HTML form fields, REST requests, URL parameters,
HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow
lists).
Control Name 3: Verify that structured data is strongly typed and validated against a defined
schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail
addresses, telephone numbers, or validating that two related fields are reasonable, such as
checking that suburb and zip/postcode match).
Control Name 4: Verify that URL redirects and forwards only allow destinations which
appear on an allow list, or show a warning when redirecting to potentially untrusted content.
How to Validate: After accessing the site inspect its cookies and http requests.
POC:
Path, Max-Age, httpOnly, Secure options aren’t defined properly. Indexed DB is

also empty here.
Requirements:: Data Classification
Control Name 1: Verify that regulated private data is stored encrypted while at rest, such as
Personally Identifiable Information (PII), sensitive personal information, or data assessed likely
to be subject to EU's GDPR.
Control Name 2: Verify that regulated health data is stored encrypted while at rest, such as
medical records, medical device details, or de-anonymized research records.
Control Name 3: Verify that regulated financial data is stored encrypted while at rest, such
as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-
anonymized market or research records.
How to Validate: The first step is to gain an understanding of the type and scope of data
that is considered private and regulated. For example, Personally Identifiable Information (PII),
sensitive personal information, or data assessed likely to be subject to EU's General Data
Protection Regulation (GDPR). It's important to understand the company's data security policies
and procedures, including the encryption requirements for storing private data. This information
can usually be found in the company's security manual or in the data protection policy. Review
the source code of the application to verify that it implements encryption for storing private data.
The code should include the encryption algorithm, key length, and mode of operation. Inspect
the database schema and verify that encrypted fields are defined for private data. Also, verify
that the encryption key is stored in a secure location, such as a hardware security module
(HSM) or a key management server. Define that the encryption is functioning as intended by
conducting tests on the application. Try to retrieve private data without the encryption key and
ensure that it is not readable. Regularly monitor the logs to detect any attempts to access
private data without proper authorization. Ensure that alerts are configured to trigger in case of
unauthorized access.
Requirements: Algorithm
Control Name: Verify that all cryptographic modules fail securely, and errors are handled in
a way that does not enable Padding Oracle attacks.
How to Validate: Test the application to see how it handles cryptographic errors. Try to
induce errors in the encryption/decryption process and observe how the application behaves.
This will help you determine if the error handling mechanisms are adequate and prevent
sensitive information from being exposed.
POC:
It exposes the errors in detail which can be attacked by attackers.

Control Name 1: Verify that industry proven or government approved cryptographic
algorithms, modes, and libraries are used, instead of custom coded cryptography.
Control Name 2: Verify that encryption initialization vector, cipher configuration, and block
modes are configured securely using the latest advice.
Control Name 3: Verify that random number, encryption or hashing algorithms, key lengths,
rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect
against cryptographic breaks.
Control Name 4: Verify that known insecure block modes (i.e. ECB, etc.), padding modes
(i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and
weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards
compatibility.
Control Name 5: Verify that nonces, initialization vectors, and other single use numbers
must not be used more than once with a given encryption key. The method of generation must
be appropriate for the algorithm being used.
Control Name 6: Verify that encrypted data is authenticated via signatures, authenticated
cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.
Control Name 7: Verify that all cryptographic operations are constant-time, with no 'short-
circuit' operations in comparisons, calculations, or returns, to avoid leaking information.
How to Validate: Regularly monitor the logs to detect any unexpected or unusual behavior.
This will help you identify any issues with the cryptographic modules and allow you to take
appropriate action. Conduct a code review to understand how cryptographic operations are
implemented in the application. Look for instances where operations may be performed
differently based on the input, or where data may be leaked through side-channel attacks such
as timing or power analysis. Test the application to see if all cryptographic operations are
constant-time. This can be done by comparing the execution time of the operations with
different inputs and verifying that they are consistent. Padding Oracle attacks are a common
type of attack on encryption systems. Verify that the application is not vulnerable to Padding
Oracle attacks by testing the padding and ciphertext to determine if any information can be
leaked through the error messages. We can use tools, like: Bletchley, PadBuster, Padding
Oracle Exploitation Tool (POET), Poracle, python-padding oracle.
POC:
Source: OWASP
Requirements: Secret Management
Control Name 1: Verify that a secrets management solution such as a key vault is used to
securely create, store, control access to and destroy secrets.
Control Name 2: Verify that key material is not exposed to the application but instead uses
an isolated security module like a vault for cryptographic operations.
How to Validate: Review the architecture of the secrets management solution to ensure that
it meets industry-standard security requirements and best practices, such as using encryption,
access control, and audit logging. Check the documentation of the secrets management
solution to verify that it includes detailed information on how secrets are stored, encrypted, and
accessed. Evaluate the encryption used to protect secrets to ensure that it meets the required
level of security and uses an approved cryptographic algorithm. Test the disaster recovery
procedures for the secrets management solution to verify that secrets can be recovered in the
event of a disaster or data loss.
POC:
It doesn’t use a secret key.

Requirements:: Log Content
Control Name: Verify that the application does not log credentials or payment details.
Session tokens should only be stored in logs in an irreversible, hashed form.
How to Validate: Review the logs generated by the application to ensure that they do not
contain sensitive information. If you find any instances of sensitive information in the logs, report
this to the developers so that they can remove this information and implement proper logging
practices.
POC:
Session tokens are in hashed format.

Control Name: Verify that the application logs security relevant events including successful
and failed authentication events, access control failures, deserialization failures and input
validation failures.
practices.
POC:
It includes successful and failed authentication events in the response sector.

Control Name: Verify that each log event includes necessary information that would allow
for a detailed investigation of the timeline when an event happens.
practices.
POC:
Log event includes necessary information

Requirements: Log Processing
Control Name 1: Verify that all authentication decisions are logged, without storing sensitive
session tokens or passwords. This should include requests with relevant metadata needed for
security investigations.
Control Name 2: Verify that all access control decisions can be logged and all failed
decisions are logged. This should include requests with relevant metadata needed for security
investigations.
How to Validate: Test the logging functionality of the application to ensure that
authentication decisions are being recorded accurately and securely. This can be done by
attempting to log in to the application with test credentials and monitoring the logs to see if the
authentication decisions are being recorded correctly. Regularly monitor the logging process to
ensure that authentication decisions are being recorded accurately and securely and that
sensitive information is not being stored in the logs.
POC:
All tokens are logged.

Requirements: Log Protection
Control Name 1: Verify that all logging components appropriately encode data to prevent
log injection.
Control Name 2: Verify that security logs are protected from unauthorized access and
modification.
Control Name 3: Verify that time sources are synchronized to the correct time and time
zone. Strongly consider logging only in UTC if systems are global to assist with post-incident
forensic analysis.
How to Validate: Thoroughly review the source code of the application to identify all logging
components and determine how data is being encoded before being logged. Verify that the
encoding methods being used to encode data before it is logged are appropriate and secure.
This may include methods such as Base64 encoding, URL encoding, or HTML encoding. Test
the encoding functionality of the logging components to ensure that data is being encoded
correctly and securely. This can be done by attempting to inject malicious data into the logs and
monitoring the logs to see if the malicious data is being recorded correctly. Regularly monitor
the logging process to ensure that data is being encoded correctly and securely and that log
injection is being prevented.
POC:
It encoded the credentials as base64. I check the request on burp decoder.

Requirements: Error Handling
Control Name: Verify that a generic message is shown when an unexpected or security
sensitive error occurs, potentially with a unique ID which support personnel can use to
investigate.
How to Validate: Test the error handling functionality of the application by attempting to
trigger unexpected or security-sensitive errors. This can be done by attempting to access
restricted resources, inputting invalid data, or attempting to exploit vulnerabilities in the
application. Observe the error messages generated by the application when errors occur. Verify
that a generic message is being displayed that does not reveal sensitive information or details
about the error. Verify that a unique ID is being included in the error message that support
personnel can use to investigate the error. This ID should be unique for each error and should
allow support personnel to quickly identify and resolve the issue.
POC:
No error messages shown.
Control Name 1: Verify that exception handling (or a functional equivalent) is used across
the codebase to account for expected and unexpected error conditions.
Control Name 2: Verify that a "last resort" error handler is defined which will catch all
unhandled exceptions.
How to Validate: Test the error handling functionality of the application by attempting to
trigger unexpected or security-sensitive errors. This can be done by attempting to access
restricted resources, inputting invalid data, or attempting to exploit vulnerabilities in the
application. Observe the error messages generated by the application when errors occur. Verify
that a generic message is being displayed that does not reveal sensitive information or details
about the error. Verify that a unique ID is being included in the error message that support
personnel can use to investigate the error. This ID should be unique for each error and should
allow support personnel to quickly identify and resolve the issue.
POC:
There are no exception handling functions that's why these types of errors occur.
Requirements:: General Data Protection
Control Name 1: Verify the application protects sensitive data from being cached in server
components such as load balancers and application caches.
Control Name 2: Verify that all cached or temporary copies of sensitive data stored on the
server are protected from unauthorized access or purged/invalidated after the authorized user
accesses the sensitive data.
Control Name 3: Verify the application minimizes the number of parameters in a request,
such as hidden fields, Ajax variables, cookies and header values.
Control Name 4 :Verify the application can detect and alert on abnormal numbers of
requests, such as by IP, user, total per hour or day, or whatever makes sense for the
application.
Control Name 5: Verify that regular backups of important data are performed and that test
restoration of data is performed.
Control Name 6: Verify that backups are stored securely to prevent data from being stolen
or corrupted.
How to Validate: Review the architecture and configuration of the server components,
including load balancers and application caches, to determine how sensitive data is being
stored and protected. Verify that the application is protecting sensitive data from being cached
in server components by reviewing the source code and configuration files to ensure that
sensitive data is being encrypted, hashed, or otherwise protected before it is stored. Regularly
monitor the behavior of server components, such as load balancers and application caches, to
ensure that sensitive data is not being cached. Test the data protection mechanisms of the
application by attempting to access sensitive data from server components such as load
balancers and application caches, and verifying that the data cannot be accessed. Evaluate the
risk associated with storing sensitive data in server components, such as load balancers and
application caches, and determine if additional protection mechanisms are necessary.
POC:
Session tokens.
I generated many test cases but it didn’t generate any alerts.
Requirements: Client-side Data Protection
Control Name: Verify the application sets sufficient anti-caching headers so that sensitive
data is not cached in modern browsers.
How to Validate: Verify that the application is setting anti-caching headers that are
appropriate for the types of data being transmitted, such as the Cache-Control, Pragma, and
Expires headers.
POC:
This data isn't present there.

Control Name: Verify that data stored in browser storage (such as localStorage,
sessionStorage, IndexedDB, or cookies) does not contain sensitive data.
How to Validate: Monitor the network traffic using a tool such as Wireshark or Burp Suite or
Inspect to monitor the network traffic between the client and the server. Attempt to authenticate
to the application using valid credentials.
POC:
No local storage and session storage.

Control Name: Verify that authenticated data is cleared from client storage, such as the
browser DOM, after the client or session is terminated.
How to Validate: Log out of the application and log back in to see if a new session token is
generated each time.
POC:
So, it violates the control.
Requirements: Sensitive Private Data
Control Name 1: Verify that sensitive data is sent to the server in the HTTP message body
or headers, and that query string parameters from any HTTP verb do not contain sensitive data.
Control Name 2: Verify that users have a method to remove or export their data on demand.
Control Name 3: Verify that users are provided clear language regarding collection and use
of supplied personal information and that users have provided opt-in consent for the use of that
data before it is used in any way.
Control Name 4: Verify that all sensitive data created and processed by the application has
been identified, and ensure that a policy is in place on how to deal with sensitive data.
Control Name 5: Verify accessing sensitive data is audited (without logging the sensitive
data itself), if the data is collected under relevant data protection directives or where logging of
access is required.
Control Name 6: Verify that sensitive information contained in memory is overwritten as
soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random
data.
Control Name 7: Verify that sensitive or private information that is required to be encrypted,
is encrypted using approved algorithms that provide both confidentiality and integrity.
Control Name 8: Verify that sensitive personal information is subject to data retention
classification, such that old or out of date data is deleted automatically, on a schedule, or as the
situation requires.
How to Validate: Review the application code to determine how data is being transmitted
from the client to the server. Verify that sensitive data is being transmitted in the HTTP message
body or headers, and not as query string parameters in the URL. Regularly monitor the data
transmission from the client to the server to ensure that sensitive data is not being transmitted
as query string parameters in the URL. Test the data transmission from the client to the server
by attempting to transmit sensitive data as query string parameters in the URL and verifying that
the data is not transmitted in this manner.
POC:
These POC are given in session termination and http Security part.
Requirements:: Client Communication Security
Control Name 1: Verify that TLS is used for all client connectivity, and does not fall back to
insecure or unencrypted communications.
Control Name 2: Verify using up to date TLS testing tools that only strong cipher suites are
enabled, with the strongest cipher suites set as preferred.
Control Name 3: Verify that only the latest recommended versions of the TLS protocol are
enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the
preferred option.
How to Validate: Thoroughly review the source code of the application to identify the
network communication functions and determine how they are being secured. Verify that the
application is using TLS for all client connectivity by reviewing the source code and checking the
configuration files to ensure that the correct protocol (e.g. TLS 1.2) is being used. Test the TLS
functionality of the application by attempting to intercept network communications and verifying
that the data being transmitted is encrypted. Regularly monitor the network communication of
the application to ensure that it is being encrypted using TLS and that there is no fallback to
insecure or unencrypted communications.
POC:
The Network response.

Requirements: Server Communication Security
Control Name 1: Verify that connections to and from the server use trusted TLS certificates.
Where internally generated or self-signed certificates are used, the server must be configured to
only trust specific internal CAs and specific self-signed certificates. All others should be
rejected.
Control Name 2: Verify that encrypted communications such as TLS is used for all inbound
and outbound connections, including for management ports, monitoring, authentication, API, or
web service calls, database, cloud, serverless, mainframe, external, and partner connections.
The server must not fall back to insecure or unencrypted protocols.
Control Name 3: Verify that all encrypted connections to external systems that involve
sensitive information or functions are authenticated.
Control Name 4: Verify that proper certification revocation, such as Online Certificate Status
Protocol (OCSP) Stapling, is enabled and configured.
Control Name 5: Verify that backend TLS connection failures are logged.
How to Validate: Review the certificate configuration of the server to determine the types of
certificates that are being used. Assure that the server is using trusted TLS certificates by
checking the certificate chain and checking the certificate revocation list (CRL) or the online
certificate status protocol (OCSP) to ensure that the certificate is still valid. If the server is using
internally generated or self-signed certificates, verify that the server is configured to only trust
specific internal CAs and specific self-signed certificates. All others should be rejected.
Regularly monitor the certificate usage of the server to ensure that the correct certificates are
being used and that the certificate configuration has not been modified. Test the certificate
validation process by attempting to connect to the server using a certificate that is not trusted
and verifying that the connection is rejected.
POC:
It generates different certificates (cookies) and has a time duration of the
certificates.
Requirements:: Code Integrity
Control Name: Verify that a code analysis tool is in use that can detect potentially malicious
code, such as time functions, unsafe file operations and network connections.
How to Validate: The first step is to determine which code analysis tool is being used by the
organization. This information can typically be found in the software development
documentation or by asking the relevant individuals within the organization. We can test the
tool's ability to detect malicious code by using a sample code that contains known
vulnerabilities. The code analysis tool should flag these vulnerabilities and provide suggestions
for how to remediate them. Run the code analysis tool on a sample of the organization's
codebase to see how effective it is at detecting malicious code. If the tool is not detecting the
types of vulnerabilities you are concerned about, consider reaching out to the vendor for support
or exploring alternative code analysis tools.
POC:
There are no analyzing tools available that’s why we can inject malicious code.
Requirements: Malicious Code Search
Control Name 1: Verify that the application source code and third party libraries do not
contain unauthorized phone home or data collection capabilities. Where such functionality
exists, obtain the user's permission for it to operate before collecting any data.
Control Name 2: Verify that the application does not ask for unnecessary or excessive
permissions to privacy related features or sensors, such as contacts, cameras, microphones, or
location.
contain back doors, such as hard-coded or additional undocumented accounts or keys, code
obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging
features, or otherwise out of date, insecure, or hidden functionality that could be used
maliciously if discovered.
contain malicious code, such as salami attacks, logic bypasses, or logic bombs.
How to Validate: Thoroughly review the source code of the application to identify any
functions that may be sending data to a remote server or collecting data from the user's device.
Look for instances of network connections, data storage, and data transmission functions. Third-
party libraries are often used to add functionality to an application. These libraries may contain
code that is sending data to a remote server or collecting data from the user's device. Check the
source code of these libraries to ensure that they are not collecting data without the user's
permission. Use a network analysis tool to monitor the network traffic generated by the
application. This will allow you to see what data is being transmitted and where it is being sent.
If we find that the application or third-party libraries are collecting data from the user, ensure that
the user is aware of this and has given their permission for the data to be collected. This can be
done by adding a prompt or notification to the application that informs the user about the data
collection and requests their consent.
POC:
Database is encoded.
Requirements:: Business Logic Security
Control Name 1: Verify that the application will only process business logic flows for the
same user in sequential step order and without skipping steps.
Control Name 2: Verify that the application will only process business logic flows with all
steps being processed in realistic human time, i.e. transactions are not submitted too quickly.
Control Name 3: Verify the application has appropriate limits for specific business actions or
transactions which are correctly enforced on a per user basis.
Control Name 4: Verify that the application has anti-automation controls to protect against
excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of
service attacks.
Control Name 5: Verify the application has business logic limits or validation to protect
against likely business risks or threats, identified using threat modeling or similar
methodologies.
Control Name 6: Verify that the application does not suffer from "Time Of Check to Time Of
Use" (TOCTOU) issues or other race conditions for sensitive operations.
Control Name 7: Verify that the application monitors for unusual events or activity from a
business logic perspective. For example, attempts to perform actions out of order or actions
which a normal user would never attempt.
Control Name 8: Verify that the application has configurable alerting when automated
attacks or unusual activity is detected.
How to Validate: By identifying the various business logic flows that the application handles,
such as user registration, password reset, or purchase transactions. Study the flow of each
process and understand the order in which the steps are executed. This will help you determine
if there are any steps that can be skipped. Manually test each process by executing the steps in
order and verifying that the steps are executed correctly without any skipping. Modify the input
data in a way that would allow users to skip a step in the process. For example, if the process
requires you to enter a password, try entering a blank password or an incorrect password. Also
can use various monitoring tools and technologies to capture and analyze the application's
behavior and performance. This includes tools like application performance management (APM)
solutions, log analysis tools, and intrusion detection systems (IDS).
POC:
Here I use “facebook.com” to validate the controls. I try to log in by a number
which has no access. Then I create an account and have access to the site. It
doesn’t skip any steps. And do not give the access without verifying anything.
But, it gives the error message specifically which may attract the hackers.
Requirements:: File Upload
Control Name: Verify that the application will not accept large files that could fill up storage
or cause a denial of service.
How to Validate: Test the file upload mechanism by uploading files of varying sizes,
including large files, to see how the application handles them. Pay attention to any error
messages or notifications that are generated, and look for any indication that the application is
not able to handle large files gracefully. Monitor system resources, such as memory and disk
usage, when uploading large files to see if they cause any adverse effects. Conduct a denial of
service test to see if the application is vulnerable to a large number of file uploads or a large file
upload. This can be done manually or with automated tools, such as a load testing tool. Conduct
a penetration test to see if an attacker can exploit any weaknesses in the application's handling
of file uploads. This can be done manually or with automated tools.
POC:
It accepts a big file that contains various types of data.

Control Name: Verify that the application checks compressed files (e.g. zip, gz, docx, odt)
against maximum allowed uncompressed size and against maximum number of files before
uncompressing the file.
of file uploads. This can be done manually or with automated tools. Here I used the site
“https://www.docdroid.net/” for check.
POC:
It checks the file extension.

Control Name: Verify that a file size quota and maximum number of files per user is
enforced to ensure that a single user cannot fill up the storage with too many files, or
excessively large files.
of file uploads. This can be done manually or with automated tools. Here I used the site
“https://www.docdroid.net/” for check.
POC:
File size isn't explored by the site.

Requirements: File Integrity
Control Name: Verify that files obtained from untrusted sources are validated to be of
expected type based on the file's content.
How to Validate: Test the URL API that is used to access files to see if it is protecting
against path traversal attacks. This can be done by attempting to access files outside of the
intended directory, such as by using "../" in the URL.
POC:
Requirements: File Execution
Control Name: Verify that user-submitted filename metadata is not used directly by system
or framework filesystems and that a URL API is used to protect against path traversal.
How to Validate: Test the URL API that is used to access files to see if it is protecting
against path traversal attacks. This can be done by attempting to access files outside of the
intended directory, such as by using "../" in the URL.
POC:
Here we can not be able to get the file by api traversal as “../”.
Control Name: Verify that user-submitted filename metadata is validated or ignored to
prevent the disclosure, creation, updating or removal of local files (LFI).
How to Validate: Without proper input sanitizing, an attacker could easily modify the
input (as shown below) to manipulate the application into accessing unauthorized files and
directories from the host server using the “../” directive. This is known as Directory (Path)
Traversal. Here I use the website “http://www.textfiles.com/hacking/”
“https://textfiles.com/hacking/?page=../../../../etc/
passwd.txt”
POC:
[After requesting]
Didn’t accept the unauthorized file access request.
Control Name: Verify that user-submitted filename metadata is validated or ignored to
prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-
side Request Forgery (SSRF) attacks.
Traversal. Here I use the website “http://www.textfiles.com/hacking/”.
POC:
Accept the unauthorized file access request.

Control Name: Verify that the application protects against Reflective File Download (RFD)
by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the
response Content-Type header should be set to text/plain, and the Content-Disposition header
should have a fixed filename.
POC:
File type isn’t defined.

Control Name: Verify that untrusted file metadata is not used directly with system API or
libraries, to protect against OS command injection.
input (as shown below) to manipulate the application into accessing by OS command and
get it in burp.
POC:
[Request]
[Response]
Control Name: Verify that the application does not include and execute functionality from
untrusted sources, such as unverified content distribution networks, JavaScript libraries, node
npm libraries, or server-side DLLs.
POC:
[Request]
[Response]
It executes untrusted sources.

Requirements: File Storage
Control Name: Verify that files obtained from untrusted sources are stored outside the web
root, with limited permissions.
How to Validate: Test the access to the files stored outside of the web root, and verify that
they have limited permissions. This can be done by attempting to access the files using a web
browser or other client, or by attempting to access them through the file system.
POC:
It accepts all kinds of files and doesn't save them in other locations for safety.
Control Name: Verify that files obtained from untrusted sources are scanned by antivirus
scanners to prevent upload and serving of known malicious content.
How to Validate: Test the access to the files stored outside of the web root, and verify that
they have limited permissions. This can be done by attempting to access the files using a web
browser or other client, or by attempting to access them through the file system.
POC:
It accepts all kinds of files and doesn't save them in other locations for safety.
Requirements: File Download
Control Name: Verify that the web tier is configured to serve only files with specific file
extensions to prevent unintentional information and source code leakage. For example, backup
files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and
other extensions commonly used by editors should be blocked unless required.
How to Validate: Check the file system to see if the files obtained from untrusted sources
are stored outside of the web root, with limited permissions. This can be done using file system
utilities, such as 'ls' or 'dir', or by using a file explorer program.
POC:

Control Name: Verify that direct requests to uploaded files will never be executed as
HTML/JavaScript content.
How to Validate: Check the file system to see if the files obtained from untrusted sources
are stored outside of the web root, with limited permissions. This can be done using file system
utilities, such as 'ls' or 'dir', or by using a file explorer program.
POC:

Requirements: SSRF Protection
Control Name: Verify that the web or application server is configured with an allow list of
resources or systems to which the server can send requests or load data/files from.
How to Validate: Test for cross-site scripting (XSS) vulnerabilities by attempting to inject
malicious script into the application. If the allow list is configured correctly, the script should not
be executed. Test for cross-site request forgery (CSRF) vulnerabilities by attempting to make
unauthorized requests from a different domain. If the allow list is configured correctly, these
requests should be rejected.
POC:
Didn’t accept the unauthorized file access.

Requirements:: Generic Web Service Security
Control Name: Verify that all application components use the same encodings and parsers
to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in
SSRF and RFI attacks.
How to Validate: Test for parser bypasses, such as attempting to inject malicious data into
the application that would be interpreted differently by different parsers. Ensure that all input is
properly validated and sanitized, and that the application is not vulnerable to attacks that exploit
differences in encoding or parsing behavior. Monitor logs and audit trails for unusual or
suspicious activity, such as repeated attempts to exploit SSRF or RFI vulnerabilities. This can
help detect and prevent parsing attacks.
POC:
Didn’t accept the unauthorized access request.

Control Name: Verify API URLs do not expose sensitive information, such as the API key,
session tokens etc.
the application that would be interpreted differently by different parsers.
POC:
It didn’t show the cookie in the API request.

Control Name: Verify that requests containing unexpected or missing content types are
rejected with appropriate headers (HTTP response status 406 Unacceptable or 415
Unsupported Media Type)
the application that would be interpreted differently by different parsers.
POC:
It gives 400 Bad responses.

Requirements: RESTful Web Service
Control Name: Verify that enabled RESTful HTTP methods are a valid choice for the user or
action, such as preventing normal users using DELETE or PUT on protected API or resources.
How to Validate: Test the usage of HTTP methods, such as DELETE and PUT, to ensure
that they are only available to authorized users and actions. This could include attempting to
use the methods as a normal user or attempting to use the methods on protected API or
resources to verify that proper input validation is in place and that JSON schema validation is
being used to validate inputs before accepting them. This can help prevent attackers from
injecting malicious data into the application.
POC:
It accepts PUT requests without validating that means it is not secured.

Control Name: Verify that JSON schema validation is in place and verified before accepting
input.
POC:
It accepts PUT requests without validating json format that means it is not
secured.
Control Name: Verify that RESTful web services that utilize cookies are protected from
Cross-Site Request Forgery via the use of at least one or more of the following: double submit
cookie pattern, CSRF nonces, or Origin request header checks.
POC:
Accept the unauthorized access request.

Requirements:: Build and Deploy
Control Name: Verify that the application build and deployment processes are performed in
a secure and repeatable way, such as CI/CD automation, automated configuration
management, and automated deployment scripts.
How to Validate: Performed penetration testing on the application and the deployment
process. This will help identify any security vulnerabilities and ensure that the deployment
process is secure.
POC:
Here all the procedures are secured.

Control Name: Verify that compiler flags are configured to enable all available buffer
overflow protections and warnings, including stack randomization, data execution prevention,
and to break the build if an unsafe pointer, memory, format string, integer, or string operations
are found.
How to Validate: Performed penetration testing on the application and the deployment
process. This will help identify any security vulnerabilities and ensure that the deployment
process is secure.
POC:
Control Name: Verify that server configuration is hardened as per the recommendations of
the application server and frameworks in use.
How to Validate: Use any deploy site to see the request responses.
POC:
Control Name: Verify that the application, configuration, and all dependencies can be re-
deployed using automated deployment scripts, built from a documented and tested runbook in a
reasonable time, or restored from backups in a timely fashion.
How to Validate: Test the application server to ensure that it only accepts the HTTP
methods in use by the application. This can be done using a tool such as Burp Suite, OWASP
ZAP, or Postman.
POC:
Here request code ‘200 ok’ that means it re-deployed all the dependencies.
Control Name: Verify that authorized administrators can verify the integrity of all security
relevant configurations to detect tampering.
How to Validate: Test the application server to ensure that it only accepts the HTTP
methods in use by the application. This can be done using a tool such as Burp Suite, OWASP
ZAP, or Postman.
POC:
Requirements: Dependency
Control Name: Verify that all components are up to date, preferably using a dependency
checker during build or compile time.
How to Validate: We can check it on the compiler site to see if any kind of error
happened or not.
POC:
No errors happened.
Control Name: Verify that all unneeded features, documentation, sample applications and
configurations are removed.
How to Validate: Check it on the compiler site to see if any kind of error
happened or not.
POC:
No issues happened.
Control Name: Verify that if application assets, such as JavaScript libraries, CSS or web
fonts, are hosted externally on a Content Delivery Network (CDN) or external provider,
Subresource Integrity (SRI) is used to validate the integrity of the asset.
How to Validate: Send request and see it on Burp.
POC:
Control Name: Verify that third party components come from pre-defined, trusted and
continually maintained repositories.
How to Validate: Send request and see it on Burp.
POC:
Control Name: Verify that a Software Bill of Materials (SBOM) is maintained of all third party
libraries in use.
How to Validate: See on Compiler.
POC:
Control Name: Verify that the attack surface is reduced by sandboxing or encapsulating
third party libraries to expose only the required behavior into the application.
How to Validate: Inspect the request.
POC:
Requirements: Unintended Security Disclosure
Control Name: Verify that web or application server and application framework debug
modes are disabled in production to eliminate debug features, developer consoles, and
unintended security disclosures.
How to Validate: The configuration of the web or application server and application
framework should be verified to ensure that the debug modes are indeed disabled in production.
This can be done by reviewing the configuration files and making sure that the appropriate
settings are set to disable the debug modes.
POC:
That means Debug mode isn’t false.

Control Name: Verify that the HTTP headers or any part of the HTTP response do not
expose detailed version information of system components.
How to Validate: The configuration of the web or application server and application
framework should be verified to ensure that the debug modes are indeed disabled in production.
This can be done by reviewing the configuration files and making sure that the appropriate
settings are set to disable the debug modes.
POC:
As debug mode isn’t false, it exposes all request methods.

Requirements: HTTP Security Headers
Control Name: Verify that every HTTP response contains a Content-Type header. Also
specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and
application/xml. Content must match with the provided Content-Type header.
How to Validate: By using a tool such as a web proxy, network sniffer, or browser developer
tools to capture the HTTP responses generated by the application. Inspect the headers of each
HTTP response to ensure that they contain a Content-Type header. If a response does not
contain a Content-Type header, it should be flagged as a potential security vulnerability.
POC:
The HttpRequest is false.

Control Name: Verify that all API responses contain a Content-Disposition: attachment;
filename = "api.json" header (or other appropriate filename for the content type).
POC:
It need the json format.

Control Name: Verify that a Content Security Policy (CSP) response header is in place that
helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection
vulnerabilities.
POC:
As it discloses the URL Requests, it is vulnerable for XSS attacks.

Control Name: Verify that all responses contain a X-Content-Type-Options: nosniff header.
POC:
Set as “nosniff”.
Control Name: Verify that a Strict-Transport-Security header is included on all responses
and for all subdomains, such as Strict- Transport- Security: max-age = 15724800; include Sub-
domains.
POC:
Max set as 2892000.

Control Name: Verify that a suitable Referrer-Policy header is included to avoid exposing
sensitive information in the URL through the Referer header to untrusted parties.
POC:
As debug is true, it discloses all url requests.

Control Name: Verify that the content of a web application cannot be embedded in a third-
party site by default and that embedding of the exact resources is only allowed where necessary
by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response
headers.
POC:
It is not set as Content-Security-Policy: frame-ancestors and X-Frame-Options response

headers.
Requirements: HTTP Request Header Validation
Control Name: Verify that the application server only accepts the HTTP methods in use by
the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not
valid for the application context.
How to Validate: By analyzing the application's code and documentation to determine which
HTTP methods are in use by the application. This includes methods such as GET, POST, PUT,
DELETE, etc. Test the application server to ensure that it only accepts the HTTP methods in
use by the application. This can be done using a tool such as Burp Suite, OWASP ZAP, or
Postman to see if the application generates any errors.
POC:
HttpOnly is false.
Control Name: Verify that the supplied Origin header is not used for authentication or
access control decisions, as the Origin header can easily be changed by an attacker.
POC:
There is no supplied Origin header.

Control Name: Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-
Allow-Origin header uses a strict allow-list of trusted domains and subdomains to match against
and does not support the "null" origin.
POC:
Control Name: Verify that HTTP headers added by a trusted proxy or SSO devices, such as
a bearer token, are authenticated by the application.
POC:
A token was generated.

POC Control

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

POC Control

Uploaded by

Copyright:

Available Formats

Requirements:: Password Security

It accepts passwords whose lengths are more than or equal to 64.

Password length 127(response)

There are no responses. So, it doesn’t accept all printable unicode.

It doesn’t reveal session tokens.

No local storage and session storage.

No re-authentication occurs. So, it breaks the control.

How to Validate: Use Burp Suite to see the response.

Decoded cookie as URL.

Secure attribute isn’t set.

HttpOnly isn’t set.

How to Validate: Inspect the request and see the cookie-session.

The SameSite attribute isn’t set.

How to Validate: Inspect the request and see the cookie-session.

There is no HOST prefix in this site.

How to Validate: Inspect the request and see the cookie-session.

Path isn’t set as precise.

A general cookie setter.

How to Validate: Use Inspect to see the cookie.

It uses a static cookie named “login=test%2Ftest”.

How to Validate: Use Inspect to see the cookie generation.

Always set as 3 which breaks the control.

Control Name 1: Verify administrative interfaces use appropriate multi-factor authentication

Different behavior on different requests.

Path, Max-Age, httpOnly, Secure options aren’t defined properly. Indexed DB is

It exposes the errors in detail which can be attacked by attackers.

It doesn’t use a secret key.

Session tokens are in hashed format.

It includes successful and failed authentication events in the response sector.

Log event includes necessary information

All tokens are logged.

It encoded the credentials as base64. I check the request on burp decoder.

This data isn't present there.

No local storage and session storage.

The Network response.

It accepts a big file that contains various types of data.

It checks the file extension.

File size isn't explored by the site.

Accept the unauthorized file access request.

File type isn’t defined.

It executes untrusted sources.

It checks the file extension.

It checks the file extension.

Didn’t accept the unauthorized file access.

Didn’t accept the unauthorized access request.

It didn’t show the cookie in the API request.

It gives 400 Bad responses.

It accepts PUT requests without validating that means it is not secured.

Accept the unauthorized access request.

Here all the procedures are secured.

How to Validate: Send request and see it on Burp.

How to Validate: Send request and see it on Burp.

How to Validate: See on Compiler.

How to Validate: Inspect the request.

That means Debug mode isn’t false.

As debug mode isn’t false, it exposes all request methods.

The HttpRequest is false.

It need the json format.

As it discloses the URL Requests, it is vulnerable for XSS attacks.

Max set as 2892000.

As debug is true, it discloses all url requests.

It is not set as Content-Security-Policy: frame-ancestors and X-Frame-Options response

There is no supplied Origin header.