Api security Checklist


Discover non-production environments, not just production



Yüklə 2,4 Mb.
Pdf görüntüsü
səhifə3/26
tarix09.10.2023
ölçüsü2,4 Mb.
#153419
1   2   3   4   5   6   7   8   9   ...   26
API security

 Discover non-production environments, not just production: 
it’s critically 
important that you track lower environments including QA, UAT, staging, 
SIT, and pre-production in addition to your production environments. 
Attackers know that non-production environments often have fewer relaxed 
or no security controls, yet APIs in those environments may still allow 
access to similar sets of functionality and data. Organizations often set up 
lower environments with minimal hardening to help promote rapid 
development and integration to meet production goals and release 
schedules. Lower environments may also be Internet exposed which further 
elevates the security risk. 
2. 
 Get into the habit of tagging and labeling assets: 
the practice of labeling 
and tagging creates a type of virtuous cycle, becoming incredibly useful in 
DevOps practices and git-based workflows. Tags and labels are useful for a 
wide range of activities throughout the API lifecycle including: 
● 
Controlling versions of developed application code and 
infrastructure-as-code as seen in GitOps workflows 
● 
Powering DevOps style release patterns such as canary 
deployments and blue-green deployments 
● 
Informing access controls, traffic routing rules, and 
microsegmentation policies for the containers and container clusters 
that often power APIs and microservices.
Salt I API Security Best Practices I 6 


 ● 
Routing defect tracking tickets to appropriate owners and speeding 
up remediation 
● 
Informing API management policies and monitoring capabilities 
● 
Informing data security protections 
3. 
 Include the API dependencies of your APIs: 
expand beyond just 
homegrown APIs to also include APIs from open-source software, acquired 
application packages, and third-party SaaS services. API security concerns 
don’t begin and end with just your custom-built APIs. Vendor risk attestation 
and contractual language are useful primarily as reactive measures that 
provide for legal recourse, and they provide minimal guarantee at the 
technology layer. Organizations are inherently limited by the configuration 
options that are within their realm of control for third-party services. This 
limitation does not absolve the organization from security risk though. 
Significant gaps often exist between perceived design of an application and 
its APIs as opposed to the delivered, integrated system. The combination of 
built, integrated, and acquired APIs defines the digital supply chain that all 
organizations work within.
4. 

Yüklə 2,4 Mb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   ...   26




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azkurs.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin