API Security Checklist
Date of creation 14-09-2020 (version 1.0)
Date of Modification 29-12-2021 (version 1.1)
Document Version v1.1
Document Control LTFS/ INFOSEC/ AppSec/GDL/001
Prepared By Infosec Team
Approved By Mohd. Imran - HOD Information Security
Disclosure / Confidentiality Highly Confidential, not for external distribution
OWASP Standard Guidelines https://owasp.org/www-project-api-security/
https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Refere
https://owasp.org/www-project-top-ten/
https://owasp.org/Top10/
Copyrights All rights reserved. No part of this document may be reproduced or transmitte
without the prior permission of LTFS.
y Checklist
14-09-2020 (version 1.0)
29-12-2021 (version 1.1)
v1.1
TFS/ INFOSEC/ AppSec/GDL/001
Infosec Team
d. Imran - HOD Information Security
onfidential, not for external distribution
/owasp.org/www-project-api-security/
-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
s://owasp.org/www-project-top-ten/
https://owasp.org/Top10/
ment may be reproduced or transmitted in any form and by any means
thout the prior permission of LTFS.
The document should be considered only as a guideline that covers various aspects of security controls that nee
make use of other mediums for additional information on application security threats (OWASP, SANS, etc.) to
application landscape and implement them as part of the
The software vendor/partner is encouraged to use their own application security guidelines that are implement
product or service delivery offering. They should ensure that all checks documented here as well as additional s
1. implemented.
also Purpose
The vendor/partner shall test and provide an assurance to LTFS on all relevant application security controls im
to ascertain the same and validate the level of security posture of the appl
Secure application coding & development must be an ongoing process that should not only be done when a new
the software of existing applications.
It is the final responsibility of the LTFS stakeholder (associated with the vendor/partners) to ensure closure of
shall go-live without approval from LTFS Infosec.
As emerging cyber threats keep exploiting weaknesses in applications; security controls shall keep evolving; he
periodic basis.
2. Scope
This policy applies to acquisitions, developments, deployment and maintenance of information systems includ
developed applications which access, process and store LTFS’s information. LTFS information resourc
In case of any DB DDL/DML/DB Proc level/Master value level changes, Appsec testing shall not be applicable
f security controls that need to be implemented as part of SDLC. Hence, it is advised to
ats (OWASP, SANS, etc.) to constantly keep abreast of emerging threats impacting the
ement them as part of the SDLC.
delines that are implemented as an organization best practice, as part of their software
here as well as additional security best practice checks that they have documented are
urpose
emented.
ation security controls implemented. LTFS on its part shall conduct confirmatory tests
ecurity posture of the application before go-live.
only be done when a new application is developed, but also when there are changes to
isting applications.
ners) to ensure closure of all identified vulnerabilities prior to go-live. No application
proval from LTFS Infosec.
ols shall keep evolving; hence this document shall be reviewed and kept updated on a
ic basis.
Scope
nformation systems including business applications, off-the-shelf products, in-house
LTFS information resources in scope includes Cloud IT environment as well.
g shall not be applicable
API Security Checklist
OWASP Guidelines https://owasp.org/www-project-api-security/
https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
https://owasp.org/www-project-top-ten/
https://owasp.org/Top10/
Sr. No. Category Security Controls
1.1 Authentication & Implement proper authorization mechanism at server side
1.2 Authorization Implement server side validation for verification
1.3 Strictly disallow basic http authentication, as auth. parameters are included within every request
to the server. Can use JWT or Ouath
1.4 Use standard methods for authentication mechanisms
1.5 Use multiple parameters for authentication like (Username/Passwords, tokens etc.)
1.6 Implement authentication at multiple layers like IP whitelisting(network layer), Certificate
pinning(Transport layer), Authentication tokens(Application layer).
1.7 Implement account lockout, captcha or similar mechanism to avoid DoS attacks on the API,
particularly on the authentication mechanism.
1.8 In case of persistent authentication, Secure the storage of credentials on client device.
1.9 Implement checks on multiple sessions from different API channels
2 JWT (Json Web Token)
2.1 Use a random complicated key (JWT Secret) to make brute forcing the token very hard.
2.2 Make token expiration as short as possible.
2.3 Don't store sensitive data in the JWT payload, it can be decoded easily.
2.4 Oauth
2.5 Always validate redirect_uri server-side to allow only whitelisted URLs.
2.6 Implement encryption , hashing of values to avoid tampering of data.
2.7 Communication Use only https for communication.
Communication
2.8 Validate the visibility of the API (intranet, internet)
2.9 Use server certificate validation as applicable
3 If the operations of API permits, implement two way certificate validation to verify API consumer
as well as producer.
3.1 If possible, accept communication only from whitelisted sources.
3.2 Implement throttling mechanism such as rate limit to avoid DoS attacks.
3.3 Avoid transmitting id numbers, cc numbers etc. in plain text. If possible replace the numbers with
tokens.
3.4 Use HSTS header with SSL to avoid SSL Strip attack.
3.5 Input Validation Include dynamic content like timestamp, one time tokens to reduce possibility of replay attacks.
3.6 Disable vulnerable, unnecessary http methods.
3.7 In case of file upload functionality, implement checks for uploading only particular file types.
These checks should depend on multiple factors and not only on file extension.
3.8 Validate and sanitize user input for scripts, injection queries (SQL, NoSQL, XML etc.)
3.9 Follow secure coding practices like Secure parsing (against XXE), Strong typing (limited number of
acceptable values), Validating content type for each request/response, Avoid redirects &
4 Configure backend
forwards, use XML
specific & parser
secure to
URLavoid possibilities of execution of user input commands, DTDs.
identifiers.
4.1 Validate content-type on request Accept header (Content Negotiation) to allow only your
supported format (e.g. application/xml, application/json, etc) and respond with 406 Not
4.2 Validate content-type
Acceptable response ifofnot
posted data as you accept (e.g. application/x-wwwform-urlencoded,
matched.
multipart/form-data, application/json, etc).
4.3 Validate User input to avoid common vulnerabilities (e.g. XSS, SQLInjection, Remote Code
Execution, etc).
4.4 Don't use any sensitive data (credentials, Passwords, security tokens, or API keys) in the URL, but
use standard Authorization header.
4.5 Use an API Gateway service to enable caching, Rate Limit policies (e.g. Quota, Spike Arrest,
Concurrent Rate Limit) and deploy APIs resources dynamically.
4.6 Information WSDL files should not contain sensitive data, schema details in excess of what is required.
Disclosure
4.7 Return error codes for particular types of errors or display no error at all to the user as per the
business requirement.
4.79999999999999 Limit the access of API engine to system files.
4.89999999999999 Use return error codes in place of verbose, default error messages.
5 Check the amount of information stored in temporary files on client side.
5.09999999999999 Implement proper versioning mechanism in the API management
5.19999999999999 Log Avoid storing user credentials, keys etc. in logs or at least mask these parameters in the logs.
Management
5.29999999999999 Check verbosity of logs and keep it at the minimum as possible while satisfying the business
requirement.
5.39999999999999 Validate the contents of logs maintained by a third party if applicable.
5.49999999999999 Enable logging of transactions performed using the API at maximum integration points.
5.59999999999999 Mask sensitive data like CC numbers, aadhaar numbers etc. if it's mandatory to store these.
5.69999999999999 Processing Check if all the endpoints are protected behind authentication to avoid broken authentication
process.
Processing
5.79999999999999 User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.
5.89999999999999 Don't auto-increment IDs. Use UUID instead.
5.99999999999999 If you are parsing XML files, make sure entity parsing is not enabled to avoid XXE (XML external
entity attack).
6.09999999999999 If you are parsing XML files, make sure entity expansion is not enabled to avoid Billion
Laughs/XML bomb via exponential entity expansion attack.
6.19999999999999 Do not forget to turn the DEBUG mode OFF.
6.29999999999999 Output Implement Access-Control-Allow-Origin to required hostname, access control allow methods to required methods such as get , post, access
6.39999999999999 Send X-Content-Type-Options: nosniff header.
6.49999999999999 Send X-Frame-Options: deny header.
6.59999999999999 Implement Content-Security-Policy: default-src 'self'
6.69999999999999 Remove fingerprinting headers - X-Powered-By, Server, X-AspNet-Version etc.
6.79999999999999 Force content-type for your response, if you return application/json then your response content-
type is application/json.
6.89999999999999 Don't return sensitive data like credentials, Passwords, security tokens.
6.99999999999999 Return the proper status code according to the operation completed. (e.g. 200 OK, 400 Bad
Request, 401 Unauthorized, 405 Method Not Allowed, etc).
7.09999999999999 Implement Strict-Transport-Security: max-age=31536000 ; includeSubDomains
7.19999999999999 Implement Referrer-Policy: strict-origin
7.29999999999999 Implement Cache-Control: no-cache,no-store,must-revalidate and Pragma: no-cache
7.39999999999999 Implement X-XSS-Protection: 1; mode=block
7.49999999999999 Implement X-RateLimit-Limit: name=rate-limit,100; as required
7.59999999999999 Injection Ensure that a generic message is displayed in error messages
7.69999999999999 Ensure that Database details are not displayed in the response
7.79999999999999 Sanitize and validate data , use prepared, parameterized queries
7.89999999999999 Avoid usage of special characters, convert to < > format, use encoding
s such as get , post, access control allow credentials as false
