ជារៀងរាល់ pull request ដែលបន្ថែម ឬផ្លាស់ប្តូរចំណុចបញ្ចប់ ផ្លាស់ប្តូរផ្ទៃវាយប្រហារ API របស់អ្នក។ ឧបករណ៍សុវត្ថិភាព API ភាគច្រើនមិនកត់សម្គាល់ទេ រហូតដល់ចំណុចបញ្ចប់នោះដំណើរការ និងកំពុងទទួលយកចរាចរណ៍រួចហើយ។ នៅពេលនោះ ការជួសជុលលែងជាការផ្លាស់ប្តូរបន្ទាត់តែមួយនៅក្នុងការពិនិត្យកូដទៀតហើយ វាគឺជាការសន្ទនាឆ្លើយតបទៅនឹងឧប្បត្តិហេតុ។
សុវត្ថិភាព API គឺជាការអនុវត្តនៃការស្វែងរក និងបិទហានិភ័យនៅក្នុងរបៀបដែលកម្មវិធីមួយលាតត្រដាងចំណុចបញ្ចប់របស់វា៖ អ្នកណាអាចហៅពួកគេ ទិន្នន័យអ្វីដែលពួកគេប្រគល់មកវិញ និងថាតើពួកគេធ្វើអ្វីដែលឯកសារចែងឬអត់។
ឧបករណ៍ភាគច្រើនដែលបង្កើតឡើងសម្រាប់បញ្ហានេះសាកល្បង API នៅពេលដំណើរការ ពីខាងក្រៅ ដូចគ្នានឹងអ្នកវាយប្រហារដែរ។ វិធីសាស្រ្តនោះដំណើរការ ប៉ុន្តែវាដំណើរការបានលុះត្រាតែ API ត្រូវបានដាក់ពង្រាយ។ ស៊ីហ្គេនី វាយកផ្លូវមុន៖ វាអានកូដប្រភព និងលក្ខណៈបច្ចេកទេស API របស់អ្នក មុនពេលសំណើតែមួយទៅដល់ចំណុចបញ្ចប់។
វិធីបួនយ៉ាងដើម្បីសាកល្បង API និងអ្វីដែលចម្លើយនីមួយៗ
កម្មវិធីចាស់ទុំភាគច្រើនដំណើរការច្រើនជាងមួយក្នុងចំណោមទាំងនេះ៖
- ការធ្វើតេស្តឋិតិវន្ត វិភាគកូដប្រភព និងលក្ខណៈបច្ចេកទេស API មុនពេលដាក់ពង្រាយ។ វាឆ្លើយសំណួរថា "តើយើងទើបតែបង្ហាញអ្វី?" នេះជាវិធីសាស្រ្តដែលអត្ថបទនេះផ្តោតលើ។
- ការធ្វើតេស្តថាមវន្ត (DAST) ផ្ញើចរាចរណ៍ពិតប្រាកដទៅកាន់ API ដែលកំពុងដំណើរការ ហើយសង្កេតមើលពីរបៀបដែលវាឆ្លើយតប។ វាឆ្លើយថា "តើអ្វីដែលអាចទៅដល់ និងអាចកេងប្រវ័ញ្ចបាននៅពេលនេះ?"
- ងឿងឆ្ងល់ បោះបញ្ចូលមិនត្រឹមត្រូវ ឬមិនបានរំពឹងទុកនៅចំណុចបញ្ចប់ទៅកាន់ការគាំងលើផ្ទៃ និងការបរាជ័យនៃករណីគែម។ វាឆ្លើយសំណួរថា "តើការបំបែកអ្វីខ្លះនៅក្រោមការបញ្ចូលដែលយើងមិនបានរំពឹងទុក?"
- ការធ្វើតេស្តការជ្រៀតចូលដោយដៃ បន្ថែមការវិនិច្ឆ័យរបស់មនុស្សដើម្បីស្វែងរកចំណុចខ្វះខាតតក្កវិជ្ជាដែលឧបករណ៍ស្វ័យប្រវត្តិខកខាន។ វាឆ្លើយថា "តើអ្វីទៅជាអ្នកវាយប្រហារឆ្លាតវៃដែលចងភ្ជាប់គ្នា?"
គ្មានកម្មវិធីណាមួយណាជំនួសកម្មវិធីដទៃទៀតទេ។ ពួកគេឆ្លើយសំណួរផ្សេងៗគ្នានៅចំណុចផ្សេងៗគ្នាក្នុងវដ្តជីវិត ហើយគម្លាតដែលកម្មវិធីភាគច្រើនមានគឺជាគម្លាតដំបូង។
ហេតុអ្វីបានជាឧបករណ៍សុវត្ថិភាព API ភាគច្រើនមើលឃើញហានិភ័យយឺតពេល?
ការធ្វើតេស្តសុវត្ថិភាព Runtime API ផ្ញើចរាចរណ៍ទៅកម្មវិធីផ្ទាល់ ហើយមើលពីរបៀបដែលវាឆ្លើយតប។ វាជាស្រទាប់ស្របច្បាប់ និងចាំបាច់។ វាក៏ជាសូចនាករយឺតយ៉ាវផងដែរ៖ ចំណុចបញ្ចប់ត្រូវតែមាន ដាក់ពង្រាយ និងអាចទៅដល់បាន មុនពេលដែលម៉ាស៊ីនស្កេនពេលដំណើរការអាចនិយាយអ្វីមួយអំពីវា។ អ្វីក៏ដោយដែលវារកឃើញ ត្រូវបានលាតត្រដាងរួចហើយ មិនថាវាត្រូវការពេលយូរប៉ុណ្ណាក្នុងការស្កេនដើម្បីដំណើរការនោះទេ។
មានចន្លោះប្រហោងទីពីរនៅក្រោមបញ្ហាពេលវេលានោះ។ ឧបករណ៍ដំណើរការអាចសាកល្បងតែអ្វីដែលពួកគេដឹងថាមានប៉ុណ្ណោះ។ ប្រសិនបើចំណុចបញ្ចប់មិនដែលត្រូវបានកត់ត្រាទុក ឬលក្ខណៈបច្ចេកទេស OpenAPI ហួសសម័យនៅពេលដែលនរណាម្នាក់ដឹកជញ្ជូនផ្លូវថ្មី ម៉ាស៊ីនស្កេនដំណើរការមិនអាចដឹងថាវានៅទីនោះទេ។ វាសាកល្បងផែនទី មិនមែនទឹកដីទេ។
ការធ្វើតេស្តសុវត្ថិភាព API ឋិតិវន្ត បិទចន្លោះប្រហោងទាំងពីរដោយផ្លាស់ទីការត្រួតពិនិត្យទៅកន្លែងដែលចំណុចបញ្ចប់ត្រូវបានកំណត់៖ កូដរបស់អ្នក និងលក្ខណៈបច្ចេកទេស API របស់អ្នក មុនពេលដាក់ពង្រាយ។ pull request ដែលណែនាំចំណុចបញ្ចប់គឺ pull request ដែលបង្ហាញពីហានិភ័យរបស់វា។
តើសុវត្ថិភាព API ឋិតិវន្តមានន័យយ៉ាងណា?
Xygeni បង្កើតសារពើភ័ណ្ឌ API របស់អ្នកពីប្រភពពីរ៖ កូដប្រភពនៃកម្មវិធីរបស់អ្នក និងលក្ខណៈបច្ចេកទេស API របស់អ្នក រួមទាំង OpenAPI និង Swagger។
សារពើភ័ណ្ឌដែលមានលក្ខណៈបច្ចេកទេសតែមួយគត់បង្ហាញពីចំណុចបញ្ចប់ដែលអ្នកណាម្នាក់ត្រូវបានចងចាំដើម្បីកត់ត្រា។ សារពើភ័ណ្ឌដែលមានកូដតែមួយគត់បង្ហាញពីអ្វីដែលមាន ប៉ុន្តែមិនចាំបាច់ថាវាត្រូវបានគេចង់ប្រើយ៉ាងដូចម្តេចនោះទេ។ ការអានទាំងពីរផ្ដល់ឱ្យអ្នកនូវរូបភាពពេញលេញ៖ ចំណុចបញ្ចប់ដែលក្រុមរបស់អ្នកបានកត់ត្រា និងចំណុចដែលគ្មានអ្នកណាធ្វើ។
សារពើភ័ណ្ឌនោះគឺជាមូលដ្ឋានគ្រឹះនៃអ្វីៗផ្សេងទៀតដែលបង្កើតឡើង៖
- API សរុបដែលបានរកឃើញ និងទ្រព្យសកម្មដែលមានហានិភ័យត្រូវបានវាស់វែងទល់នឹងមូលដ្ឋាន
- ចំណុចបញ្ចប់ត្រូវបានបំបែកដោយវិធីសាស្ត្រ HTTP
- បញ្ហាដែលបានដាក់ជាក្រុមតាមសេវាកម្ម
- ចំណុចបញ្ចប់នីមួយៗជាមួយនឹងវិធីសាស្ត្រ ផ្លូវ សេវាកម្ម ម៉ូឌុល ស្ថានភាពផ្ទៀងផ្ទាត់ និងពិន្ទុហានិភ័យរបស់វា
ថ្នាក់ដឹកនាំផ្នែកវិស្វកម្មរបស់អ្នកឃើញរូបរាងផ្ទៃ API របស់អ្នកដោយមិនចាំបាច់បើកសំបុត្រសូម្បីតែមួយឡើយ។
ចំណុចបញ្ចប់នីមួយៗដែល Xygeni បានរកឃើញ ជាមួយនឹងវិធីសាស្ត្រ ស្ថានភាពផ្ទៀងផ្ទាត់ និងពិន្ទុហានិភ័យរបស់វា ត្រូវបានបង្កើតឡើងពីកូដ និងលក្ខណៈបច្ចេកទេសរួមគ្នា។
Production note ច្រឹបបន្ទះ AI Triage ពីរូបថតអេក្រង់សុវត្ថិភាព API ណាមួយ។
បានផ្គូផ្គងទៅកំពូលសុវត្ថិភាពទាំង ១០ របស់ OWASP API
ការរកឃើញបង្ហាញពីក្របខ័ណ្ឌដែលក្រុមសន្តិសុខ និងអ្នកសវនកររបស់អ្នកប្រើប្រាស់រួចហើយ។ Xygeni រកឃើញហានិភ័យនៅទូទាំង OWASP API Security កំពូលទាំង ៤ (២៤):
| OWASP ។ | ហានិភ័យ | តើវាមានន័យយ៉ាងដូចម្តេចនៅក្នុងការអនុវត្ត |
|---|---|---|
API1 | ការអនុញ្ញាតកម្រិតវត្ថុដែលខូច | ចំណុចបញ្ចប់មួយប្រគល់ ឬកែប្រែទិន្នន័យដែលជាកម្មសិទ្ធិរបស់អ្នកប្រើប្រាស់ ឬអ្នកជួលផ្សេងទៀត |
API2 | ចំណុចបញ្ចប់ដែលមិនបានផ្ទៀងផ្ទាត់ | ផ្លូវមួយអាចទៅដល់បានដោយមិនចាំបាច់មានការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវទាល់តែសោះ |
API3 | ការប៉ះពាល់ទិន្នន័យច្រើនពេក | ការឆ្លើយតបមួយបង្ហាញវាលច្រើនជាងអ្វីដែលអ្នកហៅចូលត្រូវការ ឬគួរតែឃើញ។ |
API3 | ការចាត់តាំងម៉ាស | ចំណុចបញ្ចប់ទទួលយក និងអនុវត្តវាលដែលវាមិនដែលត្រូវបានសន្មត់ថាទទួលយក |
API3 / API10 | ទិន្នន័យរសើបនៅក្នុងការឆ្លើយតប | PII, PCI ឬ PHI ទៅដល់អតិថិជនពីចំណុចបញ្ចប់ដែលមិនគួរផ្ញើវា |
API4 | ដែនកំណត់អត្រាដែលបាត់ | ចំណុចបញ្ចប់មិនមានការការពារប្រឆាំងនឹងការរំលោភបំពាន ឬការហៅទូរសព្ទដោយប្រើកម្លាំងខ្លាំងនោះទេ។ |
API5 | ការអនុញ្ញាតកម្រិតមុខងារដែលខូច | ចំណុចបញ្ចប់មួយអនុវត្តសកម្មភាពដែលមានសិទ្ធិដោយមិនចាំបាច់ពិនិត្យមើលថាអ្នកហៅត្រូវបានអនុញ្ញាតឱ្យ |
API7 | SSRF | API អាចត្រូវបានបញ្ឆោតឱ្យធ្វើការស្នើសុំក្នុងនាមអ្នកវាយប្រហារ |
API8 | ការកំណត់រចនាសម្ព័ន្ធ JWT មិនត្រឹមត្រូវ | ការផ្ទៀងផ្ទាត់សញ្ញាសម្ងាត់ ការចុះហត្ថលេខា ឬការផុតកំណត់ត្រូវបានរៀបចំមិនត្រឹមត្រូវ |
API8 | ការកំណត់រចនាសម្ព័ន្ធ CORS មិនត្រឹមត្រូវ | ច្បាប់ឆ្លងប្រភពដើមគឺអនុញ្ញាតគ្រប់គ្រាន់ដើម្បីអាចកេងប្រវ័ញ្ចបាន |
API9 | ចំណុចបញ្ចប់ Zombie និងក្មេងកំព្រា | ផ្លូវដែលលែងប្រើ ឬត្រូវបានបំភ្លេចចោល ដែលនៅតែអាចទៅដល់បាន និងផ្លូវដែលគ្មានអ្នកណាជាម្ចាស់ |
ប្រភេទមួយត្រូវបានអវត្តមានដោយចេតនា។ API6 ដែលជាការចូលប្រើដោយគ្មានការរឹតត្បិតចំពោះលំហូរអាជីវកម្មដែលងាយរងគ្រោះ តម្រូវឱ្យមានការយល់ដឹងអំពីអ្វីដែលដំណើរការអាជីវកម្មគួរអនុញ្ញាត ហើយគ្មានអ្នកវិភាគឋិតិវន្តណាម្នាក់រកឃើញរឿងនោះដោយភាពជឿជាក់នោះទេ។ អ្នកលក់ណាដែលអះអាងផ្ទុយពីនេះកំពុងលក់ប្រអប់ធីកឱ្យអ្នក។ មួយនោះនៅតែស្ថិតនៅជាមួយការធ្វើគំរូគំរាមកំហែង និងឧបករណ៍សាកល្បងការជ្រៀតចូលរបស់អ្នក។
មិនមែនរាល់ការរកឃើញទាំងអស់សុទ្ធតែដូចគ្នាទេ៖ ភាពរសើបនៃទិន្នន័យ និងការរួមបញ្ចូលគ្នាដ៏គ្រោះថ្នាក់
បញ្ជីការរកឃើញរាបស្មើចាត់ទុកចំណុចបញ្ចប់នៃការត្រួតពិនិត្យសុខភាពដែលមិនបានផ្ទៀងផ្ទាត់ដូចគ្នានឹងចំណុចបញ្ចប់ដែលមិនបានផ្ទៀងផ្ទាត់ដែលប្រគល់កំណត់ត្រាអតិថិជន។ ទាំងនោះមិនមែនជាបញ្ហាដូចគ្នាទេ ហើយគំរូអាទិភាពដែលដាក់ពិន្ទុពួកវាដូចគ្នាបណ្តុះបណ្តាលក្រុមរបស់អ្នកឱ្យមិនអើពើនឹងបញ្ជី។
Xygeni ចាត់ថ្នាក់ទិន្នន័យដែលចំណុចបញ្ចប់នីមួយៗដោះស្រាយ ដោយដាក់ទង់ PII, PCI និង PHI នៅក្នុងប៉ារ៉ាម៉ែត្រសំណើ និងក្នុងការឆ្លើយតប ហើយផ្គូផ្គងវាជាមួយនឹងស្ថានភាពផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវរបស់ចំណុចបញ្ចប់។
វាក៏ភ្ជាប់ទំនាក់ទំនងការរកឃើញដែលធ្លាក់លើចំណុចបញ្ចប់ដូចគ្នា និងបង្កើនភាពធ្ងន់ធ្ងរនៅពេលដែលវាកាន់តែធ្ងន់ធ្ងរ។ ការលេចធ្លាយ PII នៅក្នុងការឆ្លើយតបគឺជាការរកឃើញដ៏ធ្ងន់ធ្ងរមួយដោយខ្លួនឯង។ ការលេចធ្លាយដូចគ្នានៅលើចំណុចបញ្ចប់ដែលមិនតម្រូវឱ្យមានការផ្ទៀងផ្ទាត់គឺមានសារៈសំខាន់ ហើយវេទិកានេះដាក់ពិន្ទុវាតាមវិធីនោះជំនួសឱ្យការទុកការតភ្ជាប់ឱ្យនរណាម្នាក់កត់សម្គាល់ដោយដៃ។
ចំណុចបញ្ចប់ Zombie និង Orphan៖ ការរសាត់រវាងកូដ និង Spec
ដោយសារតែ Xygeni អានកូដរបស់អ្នក និងលក្ខណៈបច្ចេកទេស API របស់អ្នកនៅក្បែរគ្នា វាមើលឃើញកន្លែងដែលពួកគេមិនយល់ស្រប។ ភាពរសាត់នោះបង្ហាញជាគំរូដែលអាចសម្គាល់បានចំនួនបី៖
- ចំណុចបញ្ចប់ដែលមិនមានឯកសារ។ ពួកវារស់នៅក្នុងលេខកូដ ហើយមិនដែលត្រូវបានបន្ថែមទៅក្នុងលក្ខណៈបច្ចេកទេសនោះទេ។
- ចំណុចបញ្ចប់របស់ Zombie។ ពួកវាត្រូវបានសម្គាល់ថាលែងប្រើ ឬចូលនិវត្តន៍ ហើយពួកគេនៅតែអាចទាក់ទងបាន។
- ចំណុចបញ្ចប់កំព្រា។ គ្មាននរណាម្នាក់នៅក្នុងក្រុមបច្ចុប្បន្នជាម្ចាស់វាទេ។
គ្មានរបស់ទាំងនេះបង្ហាញក្នុងសារពើភ័ណ្ឌដែលមានតែលក្ខណៈពិសេសទេ ព្រោះលក្ខណៈពិសេសគឺជាអ្វីដែលពួកគេមិនមាន។
ភស្តុតាងដែលអ្នកអាចអនុវត្តបាន មិនមែនជាសំបុត្រសម្រាប់ស៊ើបអង្កេតទេ
ការរកឃើញនីមួយៗចង្អុលបង្ហាញពីអ្នកដោះស្រាយពិតប្រាកដដែលទទួលខុសត្រូវ៖ ឯកសារ ថ្នាក់ វិធីសាស្ត្រ និងបន្ទាត់ជាក់លាក់ដែលបានណែនាំកំហុស ជាមួយនឹងកូដដែលបង្កបញ្ហាដែលបង្ហាញជាមួយវា។ កំហុសនីមួយៗក៏មានកម្រិតធ្ងន់ធ្ងររបស់វា ប្រភេទសុវត្ថិភាព OWASP API Top 10 របស់វា CWE របស់វា ស្ថានភាពផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃចំណុចបញ្ចប់ និងការចាត់ថ្នាក់ភាពរសើបនៃទិន្នន័យដែលពាក់ព័ន្ធ។
ការរកឃើញដែលគ្រាន់តែដាក់ឈ្មោះចំណុចបញ្ចប់មួយ នឹងបញ្ជូនអ្នកអភិវឌ្ឍន៍ឱ្យស្វែងរកមូលដ្ឋានកូដមុនពេលពួកគេអាចចាប់ផ្តើមជួសជុលអ្វីមួយ។ ការរកឃើញដែលដាក់ឈ្មោះបន្ទាត់នោះ នឹងធ្វើឱ្យពួកគេជួសជុលភ្លាមៗ។
ការរកឃើញត្រូវបាននាំចេញជា JSON, CSV, Markdown និង SARIF 2.1.0 ដូច្នេះពួកវាចុះចតនៅក្នុង tools ក្រុមរបស់អ្នកធ្វើការរួចហើយ។
អ្នកដោះស្រាយ ខ្សែបន្ទាត់ និងលេខកូដដែលបានណែនាំការប៉ះពាល់។ មិនមែនជាសំបុត្រសម្រាប់ស៊ើបអង្កេតទេ។
ហេតុអ្វីបានជាវារស់នៅក្នុងវេទិកាមួយ មិនមែននៅក្នុងកុងសូលផ្សេងទៀតទេ
Xygeni ដំណើរការ API Security រួមជាមួយ SAST, SCA, សន្តិសុខសម្ងាត់, IaC និង ស្ងួត នៅក្នុងវេទិកាតែមួយ ដែលមានទំនាក់ទំនងគ្នាតាមរយៈ ASPMជំនួសឲ្យការដឹកជញ្ជូនវាជាឧបករណ៍ដាច់ដោយឡែកជាមួយឧបករណ៍របស់វាផ្ទាល់ login និងការថយក្រោយរបស់ខ្លួនឯង។
នោះសំខាន់ណាស់ ពីព្រោះការរកឃើញឋិតិវន្ត និងការរកឃើញពេលដំណើរការឆ្លើយសំណួរផ្សេងៗគ្នាអំពីចំណុចបញ្ចប់ដូចគ្នា ហើយពួកវាមានប្រយោជន៍ជាងនៅពេលជាមួយគ្នាជាជាងដាច់ដោយឡែកពីគ្នា។ ឋិតិវន្តប្រាប់អ្នកថាចំណុចបញ្ចប់មានហានិភ័យមុនពេលវាបញ្ជូន។ DAST បញ្ជាក់ពីអ្វីដែលអាចទៅដល់បាន និងអាចកេងប្រវ័ញ្ចបាន នៅពេលដែលវាកំពុងដំណើរការ។
ការបែងចែកវាទៅជាកុងសូលពីរ ហើយហានិភ័យដែលពាក់ព័ន្ធគ្នាក្លាយជាការងារដែលមិនទាន់ដោះស្រាយពីរដែលមិនទាក់ទងគ្នា។ គ្មាននរណាម្នាក់ផ្សះផ្សាពួកវាបានទេ ហើយចំណុចបញ្ចប់ដែលមិនមានឯកសារ និងមិនត្រូវបានផ្ទៀងផ្ទាត់មិនស្ថិតនៅក្នុងជួរទាំងពីរនោះទេ។
មើលផ្ទៃវាយប្រហារ API ពិតប្រាកដរបស់អ្នក។ សុវត្ថិភាព API អាចប្រើបានជា Enterprise កម្មវិធីបន្ថែមទៅក្នុងវេទិកា Xygeni ហើយការស្កេននឹងដំណើរការប្រឆាំងនឹងឃ្លាំងផ្ទាល់ខ្លួនរបស់អ្នកនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់អ្នក។
សំណួរដែលត្រូវបានសួរជាញឹកញាប់
តើវាអាចប្រាប់បានទេថាចំណុចបញ្ចប់ណាខ្លះដែលដោះស្រាយទិន្នន័យរសើប?
បាទ/ចាស៎។ Xygeni សម្គាល់ PII, PCI និង PHI នៅក្នុងប៉ារ៉ាម៉ែត្រ និងការឆ្លើយតបចំណុចបញ្ចប់ ហើយប្រើប្រាស់ការចាត់ថ្នាក់នោះដើម្បីចាត់ថ្នាក់ការរកឃើញតាមការប៉ះពាល់ពិតប្រាកដ។
តើវាអាចដំណើរការលើគ្រប់ pull request?
មែនហើយ។ ការស្កេនបន្ថែមវិភាគតែចំណុចបញ្ចប់ដែលបានផ្លាស់ប្តូរ ហើយមេនីហ្វេសដែលវាបង្កើតអាចផ្តោតការស្កេន DAST ជាបន្តបន្ទាប់លើចំណុចបញ្ចប់ដូចគ្នាទាំងនោះ ដូច្នេះការធ្វើតេស្តឋិតិវន្ត និងពេលដំណើរការនៅតែស្របទៅនឹងអ្វីដែលពិតជាបានផ្លាស់ប្តូរ។
តើកូដរបស់ខ្ញុំចាកចេញពីបរិស្ថានរបស់ខ្ញុំទេ?
ទេ។ ការស្កេនដំណើរការនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់អ្នក។ មានតែលទ្ធផលប៉ុណ្ណោះដែលត្រូវបានផ្ទុកឡើង ការពារក្នុងពេលដឹកជញ្ជូន និងពេលសម្រាក។
តើខ្ញុំទទួលបានសុវត្ថិភាព API យ៉ាងដូចម្តេច?
សុវត្ថិភាព API អាចប្រើបានជា Enterprise កម្មវិធីបន្ថែម។ ស្នើសុំ PoC ហើយវានឹងត្រូវបានកំណត់វិសាលភាពជាមួយអ្នក។





