FOREWORD BY BERNHARD MUELLER, OWASP MOBILE PROJECT 5 · owasp's stance on masvs certifications and trust marks 12 guidance for certifying mobile apps 12 using the owasp mobile security

OWASP Mobile Application Security Verification Standard v1.0 3

FOREWORDBYBERNHARDMUELLER,OWASPMOBILEPROJECT 5

FRONTISPIECE 7

ABOUTTHESTANDARD 7COPYRIGHTANDLICENSE 7

THEMOBILEAPPLICATIONSECURITYVERIFICATIONSTANDARD 8

MOBILEAPPSECMODEL 8DOCUMENTSTRUCTURE 9VERIFICATIONLEVELSINDETAIL 9RECOMMENDEDUSE 9

ASSESSMENTANDCERTIFICATION 12

OWASP'SSTANCEONMASVSCERTIFICATIONSANDTRUSTMARKS 12GUIDANCEFORCERTIFYINGMOBILEAPPS 12USINGTHEOWASPMOBILESECURITYTESTINGGUIDE(MSTG) 12THEROLEOFAUTOMATEDSECURITYTESTINGTOOLS 13OTHERUSES 13ASDETAILEDSECURITYARCHITECTUREGUIDANCE 13ASAREPLACEMENTFOROFF-THE-SHELFSECURECODINGCHECKLISTS 13ASABASISFORSECURITYTESTINGMETHODOLOGIES 13ASAGUIDEFORAUTOMATEDUNITANDINTEGRATIONTESTS 13FORSECUREDEVELOPMENTTRAINING 13

V1:ARCHITECTURE,DESIGNANDTHREATMODELINGREQUIREMENTS 14

CONTROLOBJECTIVE 14SECURITYVERIFICATIONREQUIREMENTS 14REFERENCES 14

V2:DATASTORAGEANDPRIVACYREQUIREMENTS 16

CONTROLOBJECTIVE 16DEFINITIONOFSENSITIVEDATA 16SECURITYVERIFICATIONREQUIREMENTS 16REFERENCES 17

V3:CRYPTOGRAPHYREQUIREMENTS 18


V4:AUTHENTICATIONANDSESSIONMANAGEMENTREQUIREMENTS 19

CONTROLOBJECTIVE 19


SECURITYVERIFICATIONREQUIREMENTS 19REFERENCES 19

V5:NETWORKCOMMUNICATIONREQUIREMENTS 21


V6:PLATFORMINTERACTIONREQUIREMENTS 22


V7:CODEQUALITYANDBUILDSETTINGREQUIREMENTS 23


V8:RESILIENCEREQUIREMENTS 24

CONTROLOBJECTIVE 24IMPEDEDYNAMICANALYSISANDTAMPERING 24DEVICEBINDING 25IMPEDECOMPREHENSION 25REFERENCES 25

APPENDIXA:GLOSSARY 27

APPENDIXB:REFERENCES 30


ForewordbyBernhardMueller,OWASPMobileProject

Technologicalrevolutionscanhappenquickly.Lessthanadecadeago,smartphoneswereclunkydeviceswithlittlekeyboards-expensiveplaythingsfortech-savvybusinessusers.Today,

smartphonesareanessentialpartofourlives.We'vecometorelyonthemforinformation,navigationandcommunication,andtheyareubiquitousbothinbusinessandinoursociallives.

Everynewtechnologyintroducesnewsecurityrisks,andkeepingupwiththosechangesisoneofthemainchallengesthesecurityindustryfaces.Thedefensivesideisalwaysafewstepsbehind.For

example,thedefaultreflexformanywastoapplyoldwaysofdoingthings:Smartphonesarelike

smallcomputers,andmobileappsarejustlikeclassicsoftware,sosurelythesecurityrequirementsaresimilar?Butitdoesn'tworklikethat.SmartphoneoperatingsystemsaredifferentfromDesktop

operatingsystems,andmobileappsaredifferentfromwebapps.Forexample,theclassicalmethod

ofsignature-basedvirusscanningdoesn'tmakesenseinmodernmobileOSenvironments:Notonly

isitincompatiblewiththemobileappdistributionmodel,it'salsotechnicallyimpossibleduetosandboxingrestrictions.Also,somevulnerabilityclasses,suchasbufferoverflowsandXSSissues,

arelessrelevantinthecontextofrun-of-the-millmobileappsthanin,say,Desktopappsandweb

applications(exceptionsapply).

Overtime,ourindustryhasgottenabettergriponthemobilethreatlandscape.Asitturnsout,

mobilesecurityisallaboutdataprotection:Appsstoreourpersonalinformation,pictures,

recordings,notes,accountdata,businessinformation,locationandmuchmore.Theyactasclientsthatconnectustoservicesweuseonadailybasis,andascommunicationshubsthatprocesseseach

andeverymessageweexchangewithothers.Compromiseaperson'ssmartphoneandyouget

unfilteredaccesstothatperson'slife.Whenweconsiderthatmobiledevicesaremorereadilylost

orstolenandmobilemalwareisontherise,theneedfordataprotectionbecomesevenmoreapparent.

Asecuritystandardformobileappsmustthereforefocusonhowmobileappshandle,storeand

protectsensitiveinformation.EventhoughmodernmobileoperatingsystemslikeiOSandAndroid

offergoodAPIsforsecuredatastorageandcommunication,thosehavetobeimplementedand

usedcorrectlyinordertobeeffective.Datastorage,inter-appcommunication,properusageofcryptographicAPIsandsecurenetworkcommunicationareonlysomeoftheaspectsthatrequire

carefulconsideration.

Animportantquestioninneedofindustryconsensusishowfarexactlyoneshouldgoinprotecting

theconfidentialityandintegrityofdata.Forexample,mostofuswouldagreethatamobileapp

shouldverifytheservercertificateinaTLSexchange.ButwhataboutSSLcertificatepinning?Does

notdoingitresultinavulnerability?Shouldthisbearequirementifanapphandlessensitivedata,orisitmaybeevencounter-productive?DoweneedtoencryptdatastoredinSQLitedatabases,

eventhoughtheOSsandboxestheapp?Whatisappropriateforoneappmightbeunrealisticfor

another.TheMASVSisanattempttostandardizetheserequirementsusingverificationlevelsthat

fitdifferentthreatscenarios.

Furthermore,theappearanceofrootmalwareandremoteadministrationtoolshascreatedawarenessofthefactthatmobileoperatingsystemsthemselveshaveexploitableflaws,so

containerizationstrategiesareincreasinglyusedtoaffordadditionalprotectiontosensitivedata

andpreventclient-sidetampering.Thisiswherethingsgetcomplicated.Hardware-backedsecurity

featuresandOS-levelcontainerizationsolutions,suchasAndroidforWorkandSamsungKnox,doexist,buttheyaren'tconsistentlyavailableacrossdifferentdevices.Asabandaid,itispossibleto


implementsoftware-basedprotectionmeasures-butunfortunately,therearenostandardsor

testingprocessesforverifyingthesekindsofprotections.

Asaresult,mobileappsecuritytestingreportsareallovertheplace:Forexample,sometesters

reportalackofobfuscationorrootdetectioninanAndroidappas“securityflaw”.Ontheother

hand,measureslikestringencryption,debuggerdetectionorcontrolflowobfuscationaren'tconsideredmandatory.However,thisbinarywayoflookingatthingsdoesn'tmakesensebecause

resiliencyisnotabinaryproposition:Itdependsontheparticularclient-sidethreatsoneaimsto

defendagainst.Softwareprotectionsarenotuseless,buttheycanultimatelybebypassed,sothey

mustneverbeusedasareplacementforsecuritycontrols.

TheoverallgoaloftheMASVSistoofferabaselineformobileapplicationsecurity(MASVS-L1),

whilealsoallowingfortheinclusionofdefense-in-depthmeasures(MASVS-L2)andprotectionsagainstclient-sidethreats(MASVS-R).TheMASVSismeanttoachievethefollowing:

• Providerequirementsforsoftwarearchitectsanddevelopersseekingtodevelopsecuremobileapplications;

• Offeranindustrystandardthatcanbetestedagainstinmobileappsecurityreviews;

• Clarifytheroleofsoftwareprotectionmechanismsinmobilesecurityandproviderequirementstoverifytheireffectiveness;

• Providespecificrecommendationsastowhatlevelofsecurityisrecommendedfordifferentuse-cases.

Weareawarethat100%industryconsensusisimpossibletoachieve.Nevertheless,wehopethattheMASVSisusefulinprovidingguidancethroughoutallphasesofmobileappdevelopmentand

testing.Asanopensourcestandard,theMASVSwillevolveovertime,andwewelcomeany

contributionsandsuggestions.


Frontispiece

AbouttheStandard

WelcometotheMobileApplicationSecurityVerificationStandard(MASVS)1.0.TheMASVSisacommunityefforttoestablishaframeworkofsecurityrequirementsneededtodesign,developand

testsecuremobileappsoniOSandAndroid.

TheMASVSisaculminationofcommunityeffortandindustryfeedback.Weexpectthisstandardto

evolveovertimeandwelcomefeedbackfromthecommunity.ThebestwaytogetincontactwithusisviatheOWASPMobileProjectSlackchannel:

https://owasp.slack.com/messages/project-mobile_omtg/details/

AccountscanbecreatedatthefollowingURL:

http://owasp.herokuapp.com/.

CopyrightandLicense

Copyright©2018TheOWASPFoundation.ThisdocumentisreleasedundertheCreativeCommonsAttributionShareAlike3.0license.Foranyreuseordistribution,youmustmake

cleartoothersthelicensetermsofthiswork.

ProjectLeads LeadAuthors ContributorsandReviewers

BernhardMueller,SvenSchleier

BernhardMueller AbdessamadTemmar,AbhinavSejpal,AlexanderAntukh,AnantShrivastava,BenGardiner,FrancescoStillavato,JeroenWillemsen,Nikhil Soni,PrabhantSingh,RobertoMartelloni,StephenCorbiaux,StephenReda,SjoerdLangkemper,StefaanSeys,SvenSchleier,YogeshSharma

ThisdocumentstartedasaforkoftheOWASPApplicationSecurityVerificationStandard(ASVS)writtenbyJimManico.


TheMobileApplicationSecurityVerificationStandard

TheMASVScanbeusedtoestablishalevelofconfidenceinthesecurityofmobileapps.Therequirementsweredevelopedwiththefollowingobjectivesinmind:

• Useasametric-Toprovideasecuritystandardagainstwhichexistingmobileappscanbe

comparedbydevelopersandapplicationowners;

• Useasguidance-Toprovideguidanceduringallphasesofmobileappdevelopmentand

testing;

• Useduringprocurement-Toprovideabaselineformobileappsecurityverification.

MobileAppSecModel

TheMASVSdefinestwostrictsecurityverificationlevels(L1andL2),aswellasetofreverseengineeringresiliencyrequirements(MASVS-R)thatisflexible,i.e.adaptabletoanapp-specific

threatmodel.MASVS-L1andMASVS-L2containgenericsecurityrequirementsandare

recommendedforallmobileapps(L1)andappsthathandlehighlysensitivedata(L2).MASVS-Rcoversadditionalprotectivecontrolsthatcanbeappliedifpreventingclient-sidethreatsisadesign

goal.

FulfillingtherequirementsinMASVS-L1resultsinasecureappthatfollowssecuritybestpractices

anddoesn'tsufferfromcommonvulnerabilities.MASVS-L2addsadditionaldefense-in-depth

controlssuchasSSLpinning,resultinginanappthatisresilientagainstmoresophisticatedattacks-assumingthesecuritycontrolsofthemobileoperatingsystemareintactandtheenduserisnot

viewedasapotentialadversary.Fulfillingall,orsubsetsof,thesoftwareprotectionrequirementsin

MASVS-Rhelpsimpedespecificclient-sidethreatswheretheenduserismaliciousand/orthe

mobileOSiscompromised.

NotethatsoftwareprotectioncontrolslistedinMASVS-RanddescribedintheOWASPMobileTestingGuidecanultimatelybebypassedandmustneverbeusedasareplacementforsecuritycontrols.Instead,theyareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSrequirementsinMASVSL1orL2.

Figure1:SecurityVerificationLevels.MASVS-L1providesasolidsecuritybaselinethatisappropriateformostmobileapps.

MASVS-L2addsdefense-in-depth-controls.MASVS-Rrepresentsanoptionalprotectivelayerforimpedingreverseengineeringandtampering.


DocumentStructure

ThefirstpartoftheMASVScontainsadescriptionofthesecuritymodelandavailableverification

levels,followedbyrecommendationsonhowtousethestandardinpractice.Thedetailedsecurityrequirements,alongwithamappingtotheverificationlevels,arelistedinthesecondpart.The

requirementshavebeengroupedintoeightcategories(V1toV8)basedontechnicalobjective/

scope.ThefollowingnomenclatureisusedthroughouttheMASVSandMSTG:

• Requirementcategory:MASVS-Vx,e.g.MASVS-V2:DataStorageandPrivacy• Requirement:MASVS-Vx.y,e.g.MASVS-V2.2:"Nosensitivedataiswrittentoapplicationlogs."

VerificationLevelsinDetail

MASVS-L1:StandardSecurity

AmobileappthatachievesMASVS-L1adherestomobileapplicationsecuritybestpractices.Itfulfillsbasicrequirementsintermsofcodequality,handlingofsensitivedata,andinteractionwith

themobileenvironment.Atestingprocessmustbeinplacetoverifythesecuritycontrols.Thislevelisappropriateforallmobileapplications.

MASVS-L2:Defense-in-Depth

MASVS-L2introducesadvancedsecuritycontrolsthatgobeyondthestandardrequirements.TofulfilL2,athreatmodelmustexist,andsecuritymustbeanintegralpartoftheapp'sarchitecture

anddesign.Thislevelisappropriateforapplicationsthathandlesensitivedata,suchasmobile

banking.

MASVS-R:ResiliencyAgainstReverseEngineeringandTampering

Theapphasstate-of-the-artsecurity,andisalsoresilientagainstspecific,clearlydefinedclient-sideattacks,suchastampering,modding,orreverseengineeringtoextractsensitivecodeordata.Such

anappeitherleverageshardwaresecurityfeaturesorsufficientlystrongandverifiablesoftware

protectiontechniques.MASVS-Risapplicabletoappsthathandlehighlysensitivedataandmayserveasameansofprotectingintellectualpropertyortamper-proofinganapp.

RecommendedUse

AppscanbeverifiedagainstMASVSL1orL2basedonpriorriskassessmentandoveralllevelofsecurityrequired.L1isapplicabletoallmobileapps,whileL2isgenerallyrecommendedforapps

thathandlemoresensitivedataand/orfunctionality.MASVS-R(orpartsofit)canbeappliedto

verifyresiliencyagainstspecificthreats,suchasrepackagingorextractionofsensitivedata,inadditiontopropersecurityverification.

Insummary,Thefollowingverificationtypesareavailable:

• MASVS-L1

• MASVS-L1+R

• MASVS-L2

• MASVS-L2+R


Thedifferentcombinationsreflectdifferentgradesofsecurityandresiliency.Thegoalistoallow

forflexibility:Forexample,amobilegamemightnotwarrantaddingMASVS-L2securitycontrols

suchas2-factorauthenticationforusabilityreasons,buthaveastrongbusinessneedfortamperingprevention.

WhatVerificationTypetoChoose

ImplementingtherequirementsofMASVSL2increasessecurity,whileatthesametimeincreasingcostofdevelopmentandpotentiallyworseningtheenduserexperience(theclassicaltrade-off).In

general,L2shouldbeusedforappswheneveritmakessensefromariskvs.costperspective(i.e.,

wherethepotentiallosscausedbyacompromiseconfidentialityorintegrityishigherthanthecostincurredbytheadditionalsecuritycontrols).Ariskassessmentshouldbethefirststepbefore

applyingtheMASVS.

Examples

MASVS-L1• Allmobileapps.MASVS-L1listssecuritybestpracticesthatcanbefollowedwithareasonable

impactondevelopmentcostanduserexperience.ApplytherequirementsinMASVS-L1for

anyappthatdon'tqualifyforoneofthehigherlevels.

MASVS-L2• Health-CareIndustry:Mobileappsthatstorepersonallyidentifiableinformationthat

canbeusedforidentitytheft,fraudulentpayments,oravarietyoffraudschemes.FortheUShealthcaresector,complianceconsiderationsincludetheHealthInsurancePortabilityandAccountabilityAct(HIPAA)Privacy,Security,BreachNotificationRulesandPatientSafetyRule.

• FinancialIndustry:Appsthatenableaccesstohighlysensitiveinformationlikecreditcardnumbers,personalinformation,orallowtheusertomovefunds.Theseappswarrantadditionalsecuritycontrolstopreventfraud.FinancialappsneedtoensurecompliancetothePaymentCardIndustryDataSecurityStandard(PCIDSS),GrammLeechBlileyActandSarbanes-OxleyAct(SOX).

MASVSL1+R• MobileappswhereIPprotectionisabusinessgoal.Theresiliencycontrolslistedin

MASVS-Rcanbeusedtoincreasetheeffortneededtoobtaintheoriginalsourcecodeandtoimpedetampering/cracking.

• GamingIndustry:Gameswithanessentialneedtopreventmoddingandcheating,suchascompetitiveonlinegames.Cheatingisanimportantissueinonlinegames,asalargeamountofcheatersleadstoadisgruntledtheplayerbaseandcanultimatelycauseagametofail.MASVS-Rprovidesbasicanti-tamperingcontrolstohelpincreasetheeffortforcheaters.


MASVSL2+R• FinancialIndustry:Onlinebankingappsthatallowtheusertomovefunds,where

techniquescodeinjectionandinstrumentationoncompromiseddevicesposearisk.Inthiscase,controlsfromMASVS-Rcanbeusedtoimpedetampering,raisingthebarformalwareauthors.

• Allmobileappsthat,bydesign,needtostoresensitivedataonthemobiledevice,andatthesametimemustsupportawiderangeofdevicesandoperatingsystemversions.Inthiscase,resiliencycontrolscanbeusedasandefense-in-depthmeasuretoincreasetheeffortforattackersaimingtoextractthesensitivedata.


AssessmentandCertification

OWASP'sStanceonMASVSCertificationsandTrustMarks

OWASP,asavendor-neutralnot-for-profitorganization,doesnotcertifyanyvendors,verifiersorsoftware.

Allsuchassuranceassertions,trustmarks,orcertificationsarenotofficiallyvetted,registered,or

certifiedbyOWASP,soanorganizationrelyinguponsuchaviewneedstobecautiousofthetrust

placedinanythirdpartyortrustmarkclaimingASVScertification.

Thisshouldnotinhibitorganizationsfromofferingsuchassuranceservices,aslongastheydonot

claimofficialOWASPcertification.

GuidanceforCertifyingMobileApps

TherecommendedwayofverifyingcomplianceofamobileappwiththeMASVSisbyperformingan

"openbook"review,meaningthatthetestersaregrantedaccesstokeyresourcessuchasarchitectsanddevelopersoftheapp,projectdocumentation,sourcecode,andauthenticatedaccessto

endpoints,includingaccesstoatleastoneuseraccountforeachrole.

ItisimportanttonotethattheMASVSonlycoverssecurityofthe(client-side)mobileappandthe

networkcommunicationbetweentheappanditsremoteendpoint(s),aswellasafewbasicand

genericrequirementsrelatedtouserauthenticationandsessionmanagement.Itdoesnotcontainspecificrequirementsfortheremoteservices(e.g.webservices)associatedwiththeapp,safefora

limitedsetofgenericrequirementspertainingtoauthenticationandsessionmanagement.

However,MASVSV1specifiesthatremoteservicesmustbecoveredbytheoverallthreatmodel,

andbeverifiedagainstappropriatestandards,suchastheOWASPASVS.

Acertifyingorganizationmustincludeinanyreportthescopeoftheverification(particularlyifa

keycomponentisoutofscope),asummaryofverificationfindings,includingpassedandfailedtests,withclearindicationsofhowtoresolvethefailedtests.Keepingdetailedworkpapers,

screenshotsormovies,scriptstoreliablyandrepeatedlyexploitanissue,andelectronicrecordsof

testing,suchasinterceptingproxylogsandassociatednotessuchasacleanuplist,isconsidered

standardindustrypractice.Itisnotsufficienttosimplyrunatoolandreportonthefailures;thisdoesnotprovidesufficientevidencethatallissuesatacertifyinglevelhavebeentestedandtested

thoroughly.Incaseofdispute,thereshouldbesufficientsupportiveevidencetodemonstratethat

everyverifiedrequirementhasindeedbeentested.

UsingtheOWASPMobileSecurityTestingGuide(MSTG)

TheOWASPMSTGisamanualfortestingthesecurityofmobileapps.Itdescribesthetechnical

processesforverifyingtherequirementslistedintheMASVS.TheMSTGincludesalistoftestcases,eachofwhichmaptoarequirementintheMASVS.WhiletheMASVSrequirementsarehigh-level

andgeneric,theMSTGprovidesin-depthrecommendationsandtestingproceduresonaper-

mobile-OSbasis.


TheRoleofAutomatedSecurityTestingTools

Theuseofsourcecodescannersandblack-boxtestingtoolsisencouragedinordertoincrease

efficiencywheneverpossible.ItishowevernotpossibletocompleteMASVSverificationusingautomatedtoolsalone:Everymobileappisdifferent,andunderstandingtheoverallarchitecture,

businesslogic,andtechnicalpitfallsofthespecifictechnologiesandframeworksbeingused,isa

mandatoryrequirementtoverifysecurityoftheapp.

OtherUses

AsDetailedSecurityArchitectureGuidance

OneofthemorecommonusesfortheMobileApplicationSecurityVerificationStandardisasaresourceforsecurityarchitects.Thetwomajorsecurityarchitectureframeworks,SABSAorTOGAF,

aremissingagreatdealofinformationthatisnecessarytocompletemobileapplicationsecurityarchitecturereviews.MASVScanbeusedtofillinthosegapsbyallowingsecurityarchitectsto

choosebettercontrolsforissuescommontomobileapps.

AsaReplacementforOff-the-shelfSecureCodingChecklists

ManyorganizationscanbenefitfromadoptingtheMASVS,bychoosingoneofthetwolevels,orbyforkingMASVSandchangingwhatisrequiredforeachapplication'srisklevelinadomain-specific

way.Weencouragethistypeofforkingaslongastraceabilityismaintained,sothatifanapphaspassedrequirement4.1,thismeansthesamethingforforkedcopiesasthestandardevolves.

AsaBasisforSecurityTestingMethodologies

AgoodmobileappsecuritytestingmethodologyshouldcoverallrequirementslistedintheMASVS.TheOWASPMobileSecurityTestingGuide(MSTG)describesblack-boxandwhite-boxtestcasesfor

eachverificationrequirement.

AsaGuideforAutomatedUnitandIntegrationTests

TheMASVSisdesignedtobehighlytestable,withthesoleexceptionofarchitecturalrequirements.

Automatedunit,integrationandacceptancetestingbasedontheMASVSrequirementscanbeintegratedinthecontinuousdevelopmentlifecycle.Thisnotonlyincreasesdevelopersecurity

awareness,butalsoimprovestheoverallqualityoftheresultingapps,andreducestheamountof

findingsduringsecuritytestinginthepre-releasephase.

ForSecureDevelopmentTraining

MASVScanalsobeusedtodefinecharacteristicsofsecuremobileapps.Many"securecoding"coursesaresimplyethicalhackingcourseswithalightsmearofcodingtips.Thisdoesnothelpdevelopers.Instead,securedevelopmentcoursescanusetheMASVS,withastrongfocusonthe

proactivecontrolsdocumentedintheMASVS,ratherthane.g.theTop10codesecurityissues.


V1:Architecture,DesignandThreatModelingRequirements

ControlObjective

Inaperfectworld,securitywouldbeconsideredthroughoutallphasesofdevelopment.Inrealityhowever,securityisoftenonlyaconsiderationatalatestageintheSDLC.Besidesthetechnical

controls,theMASVSrequiresprocessestobeinplacethatensurethatthesecurityhasbeenexplicitlyaddressedwhenplanningthearchitectureofthemobileapp,andthatthefunctionaland

securityrolesofallcomponentsareknown.Sincemostmobileapplicationsactasclientstoremote

services,itmustbeensuredthatappropriatesecuritystandardsarealsoappliedtothoseservices-

testingthemobileappinisolationisnotsufficient.

Thecategory“V1”listsrequirementspertainingtoarchitectureanddesignoftheapp.Assuch,this

istheonlycategorythatdoesnotmaptotechnicaltestcasesintheOWASPMobileTestingGuide.Tocovertopicssuchasthreatmodelling,secureSDLC,keymanagement,usersoftheMASVSshould

consulttherespectiveOWASPprojectsand/orotherstandardssuchastheoneslinkedbelow.

SecurityVerificationRequirements

TherequirementsforMASVS-L1andMASVS-L2arelistedbelow.

# Description L1 L2

1.1 Allappcomponentsareidentifiedandknowntobeneeded. � �

1.2 Securitycontrolsareneverenforcedonlyontheclientside,butontherespectiveremoteendpoints.

� �

1.3 Ahigh-levelarchitectureforthemobileappandallconnectedremoteservices

hasbeendefinedandsecurityhasbeenaddressedinthatarchitecture.� �

1.4 Dataconsideredsensitiveinthecontextofthemobileappisclearlyidentified. � �

1.5 Allappcomponentsaredefinedintermsofthebusinessfunctionsand/or

securityfunctionstheyprovide.

�

1.6 Athreatmodelforthemobileappandtheassociatedremoteserviceshasbeenproducedthatidentifiespotentialthreatsandcountermeasures.

�

1.7 Allsecuritycontrolshaveacentralizedimplementation. �

1.8 Thereisanexplicitpolicyforhowcryptographickeys(ifany)aremanaged,andthelifecycleofcryptographickeysisenforced.Ideally,followakeymanagement

standardsuchasNISTSP800-57.

�

1.9 Amechanismforenforcingupdatesofthemobileappexists. �

1.10 Securityisaddressedwithinallpartsofthesoftwaredevelopmentlifecycle. �

References

Formoreinformation,seealso:

• OWASPMobileTop10:M10-ExtraneousFunctionality:

https://www.owasp.org/index.php/Mobile_Top_10_2016-M10-Extraneous_Functionality


• OWASPSecurityArchitecturecheatsheet:

https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet

• OWASPThreadmodelling:https://www.owasp.org/index.php/Application_Threat_Modeling

• OWASPSecureSDLCCheatSheet:

https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet

• MicrosoftSDL:https://www.microsoft.com/en-us/sdl/

• NISTSP800-57:http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf


V2:DataStorageandPrivacyRequirements

ControlObjective

Theprotectionofsensitivedata,suchasusercredentialsandprivateinformation,isakeyfocusinmobilesecurity.Firstly,sensitivedatacanbeunintentionallyexposedtootherappsrunningonthe

samedeviceifoperatingsystemmechanismslikeIPCareusedimproperly.Datamayalsounintentionallyleaktocloudstorage,backups,orthekeyboardcache.Additionally,mobiledevices

canbelostorstolenmoreeasilycomparedtoothertypesofdevices,soanadversarygaining

physicalaccessisamorelikelyscenario.Inthatcase,additionalprotectionscanbeimplementedto

makeretrievingthesensitivedatamoredifficult.

Notethat,astheMASVSisapp-centric,itdoesnotcoverdevice-levelpoliciessuchasthoseenforced

byMDMsolutions.WeencouragetheuseofsuchpoliciesinanEnterprisecontexttofurtherenhancedatasecurity.

DefinitionofSensitiveData

SensitivedatainthecontextoftheMASVSpertainstobothusercredentialsandanyotherdataconsideredsensitiveintheparticularcontext,suchas:

• Personallyidentifiableinformation(PII)thatcanbeabusedforidentitytheft:Socialsecurity

numbers,creditcardnumbers,bankaccountnumbers,healthinformation;

• Highlysensitivedatathatwouldleadtoreputationalharmand/orfinancialcostsif

compromised:Contractualinformation,informationcoveredbynon-disclosureagreements,

managementinformation;

• Anydatathatmustbeprotectedbylaworforcompliancereasons.

SecurityVerificationRequirements

Thevastmajorityofdatadisclosureissuescanbepreventedbyfollowingsimplerules.Mostofthecontrolslistedinthischapteraremandatoryforallverificationlevels.

# Description L1 L2

2.1 Systemcredentialstoragefacilitiesareusedappropriatelytostoresensitivedata,suchasusercredentialsorcryptographickeys.

� �

2.2 Nosensitivedataiswrittentoapplicationlogs. � �

2.3 Nosensitivedataissharedwiththirdpartiesunlessitisanecessarypartofthearchitecture.

� �

2.4 Thekeyboardcacheisdisabledontextinputsthatprocesssensitivedata. � �

2.5 Theclipboardisdeactivatedontextfieldsthatmaycontainsensitivedata. � �

2.6 NosensitivedataisexposedviaIPCmechanisms. � �

2.7 Nosensitivedata,suchaspasswordsorpins,isexposedthroughtheuserinterface.

� �

2.8 Nosensitivedataisincludedinbackupsgeneratedbythemobileoperatingsystem.

�


2.9 Theappremovessensitivedatafromviewswhenbackgrounded. �

2.10 Theappdoesnotholdsensitivedatainmemorylongerthannecessary,andmemoryisclearedexplicitlyafteruse.

�

2.11 Theappenforcesaminimumdevice-access-securitypolicy,suchasrequiringthe

usertosetadevicepasscode.

�

2.12 Theappeducatestheuseraboutthetypesofpersonallyidentifiableinformationprocessed,aswellassecuritybestpracticestheusershouldfollowinusingthe

app.

�

References

TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.

• ForAndroid-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md

• ForiOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06d-Testing-Data-Storage.md


• OWASPMobileTop10:M2-InsecureDataStorage:https://www.owasp.org/index.php/Mobile_Top_10_2016-M2-Insecure_Data_Storage

• CWE:https://cwe.mitre.org/data/definitions/922.html


V3:CryptographyRequirements

ControlObjective

Cryptographyisanessentialingredientwhenitcomestoprotectingdatastoredonamobiledevice.Itisalsoacategorywherethingscangohorriblywrong,especiallywhenstandardconventionsare

notfollowed.Thepurposeofthecontrolsinthischapteristoensurethattheverifiedapplicationusescryptographyaccordingtoindustrybestpractices,including:

• Useofprovencryptographiclibraries;

• Properchoiceandconfigurationofcryptographicprimitives;

• Asuitablerandomnumbergeneratorwhereverrandomnessisrequired.

SecurityVerificationRequirements# Description L1 L2

3.1 Theappdoesnotrelyonsymmetriccryptographywithhardcodedkeysasasolemethodofencryption.

� �

3.2 Theappusesprovenimplementationsofcryptographicprimitives. � �

3.3 Theappusescryptographicprimitivesthatareappropriatefortheparticularuse-case,configuredwithparametersthatadheretoindustrybestpractices.

� �

3.4 Theappdoesnotusecryptographicprotocolsoralgorithmsthatarewidelyconsidereddepreciatedforsecuritypurposes.

� �

3.5 Theappdoesn'tre-usethesamecryptographickeyformultiplepurposes. � �

3.6 Allrandomvaluesaregeneratedusingasufficientlysecurerandomnumbergenerator.

� �

References


• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-Testing-

Cryptography.md

• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06e-Testing-

Cryptography.md


• OWASPMobileTop10:M5-InsufficientCryptography



V4:AuthenticationandSessionManagementRequirements

ControlObjective

Inmostcases,usersloggingintoaremoteserviceisanintegralpartoftheoverallmobileapparchitecture.Eventhoughmostofthelogichappensattheendpoint,MASVSdefinessomebasic

requirementsregardinghowuseraccountsandsessionsaretobemanaged.


4.1 Iftheappprovidesusersaccesstoaremoteservice,someformofauthentication,suchasusername/passwordauthentication,isperformedatthe

remoteendpoint.

� �

4.2 Ifstatefulsessionmanagementisused,theremoteendpointusesrandomly

generatedsessionidentifierstoauthenticateclientrequestswithoutsendingtheuser'scredentials.

� �

4.3 Ifstatelesstoken-basedauthenticationisused,theserverprovidesatokenthathasbeensignedusingasecurealgorithm.

� �

4.4 Theremoteendpointterminatestheexistingsessionwhentheuserlogsout. � �

4.5 Apasswordpolicyexistsandisenforcedattheremoteendpoint. � �

4.6 Theremoteendpointimplementsamechanismtoprotectagainstthesubmissionofcredentialsanexcessivenumberoftimes.

� �

4.7 Biometricauthentication,ifany,isnotevent-bound(i.e.usinganAPIthatsimplyreturns"true"or"false").Instead,itisbasedonunlockingthe

keychain/keystore.

�

4.8 Sessionsareinvalidatedattheremoteendpointafterapredefinedperiodofinactivityandaccesstokensexpire.

�

4.9 Asecondfactorofauthenticationexistsattheremoteendpointandthe2FA

requirementisconsistentlyenforced.

�

4.10 Sensitivetransactionsrequirestep-upauthentication. �

4.11 Theappinformstheuserofallloginactivitieswiththeiraccount.Usersareable

viewalistofdevicesusedtoaccesstheaccount,andtoblockspecificdevices.

�

References


• ForAndroid-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-

Testing-Authentication.md

• ForiOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-

Authentication-and-Session-Management.md



• OWASPMobileTop10:M4-InsecureAuthentication,M6-InsecureAuthorization



V5:NetworkCommunicationRequirements

ControlObjective

Thepurposeofthecontrolslistedinthissectionistoensuretheconfidentialityandintegrityofinformationexchangedbetweenthemobileappandremoteserviceendpoints.Attheveryleast,a

mobileappmustsetupasecure,encryptedchannelfornetworkcommunicationusingtheTLSprotocolwithappropriatesettings.Level2listsadditionaldefense-in-depthmeasuresuchasSSL

pinning.


5.1 DataisencryptedonthenetworkusingTLS.Thesecurechannelisusedconsistentlythroughouttheapp.

� �

5.2 TheTLSsettingsareinlinewithcurrentbestpractices,orascloseaspossibleifthemobileoperatingsystemdoesnotsupporttherecommendedstandards.

� �

5.3 TheappverifiestheX.509certificateoftheremoteendpointwhenthesecurechannelisestablished.OnlycertificatessignedbyatrustedCAareaccepted.

� �

5.4 Theappeitherusesitsowncertificatestore,orpinstheendpointcertificateorpublickey,andsubsequentlydoesnotestablishconnectionswithendpointsthat

offeradifferentcertificateorkey,evenifsignedbyatrustedCA.

�

5.5 Theappdoesn'trelyonasingleinsecurecommunicationchannel(emailorSMS)

forcriticaloperations,suchasenrollmentsandaccountrecovery.

�

5.6 Theapponlydependsonup-to-dateconnectivityandsecuritylibraries. �

References


• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-

Network-Communication.md

• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06g-Testing-

Network-Communication.md


• OWASPMobileTop10:M3-InsecureCommunication:

https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication




V6:PlatformInteractionRequirements

ControlObjective

ThecontrolsinthisgroupensurethattheappusesplatformAPIsandstandardcomponentsinasecuremanner.Additionally,thecontrolscovercommunicationbetweenapps(IPC).


6.1 Theapponlyrequeststheminimumsetofpermissionsnecessary. � �

6.2 Allinputsfromexternalsourcesandtheuserarevalidatedandifnecessarysanitized.ThisincludesdatareceivedviatheUI,IPCmechanismssuchasintents,

customURLs,andnetworksources.

� �

6.3 TheappdoesnotexportsensitivefunctionalityviacustomURLschemes,unlessthesemechanismsareproperlyprotected.

� �

6.4 TheappdoesnotexportsensitivefunctionalitythroughIPCfacilities,unlessthesemechanismsareproperlyprotected.

� �

6.5 JavaScriptisdisabledinWebViewsunlessexplicitlyrequired. � �

6.6 WebViewsareconfiguredtoallowonlytheminimumsetofprotocolhandlersrequired(ideally,onlyhttpsissupported).Potentiallydangeroushandlers,such

asfile,telandapp-id,aredisabled.

� �

6.7 IfnativemethodsoftheappareexposedtoaWebView,verifythattheWebViewonlyrendersJavaScriptcontainedwithintheapppackage.

� �

6.8 Objectdeserialization,ifany,isimplementedusingsafeserializationAPIs. � �

References


• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-

Platform-Interaction.md

• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06h-Testing-

Platform-Interaction.md


• OWASPMobileTop10:M1-ImproperPlatformUsage




V7:CodeQualityandBuildSettingRequirements

ControlObjective

Thegoalofthiscontrolistoensurethatbasicsecuritycodingpracticesarefollowedindevelopingtheapp,andthat"free"securityfeaturesofferedbythecompilerareactivated.


7.1 Theappissignedandprovisionedwithvalidcertificate. � �

7.2 Theapphasbeenbuiltinreleasemode,withsettingsappropriateforareleasebuild(e.g.non-debuggable).

� �

7.3 Debuggingsymbolshavebeenremovedfromnativebinaries. � �

7.4 Debuggingcodehasbeenremoved,andtheappdoesnotlogverboseerrorsordebuggingmessages.

� �

7.5 Allthirdpartycomponentsusedbythemobileapp,suchaslibrariesand

frameworks,areidentified,andcheckedforknownvulnerabilities.� �

7.6 Theappcatchesandhandlespossibleexceptions. � �

7.7 Errorhandlinglogicinsecuritycontrolsdeniesaccessbydefault. � �

7.8 Inunmanagedcode,memoryisallocated,freedandusedsecurely. � �

7.9 Freesecurityfeaturesofferedbythetoolchain,suchasbyte-codeminification,

stackprotection,PIEsupportandautomaticreferencecounting,areactivated.� �

References


• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-

Code-Quality-and-Build-Settings.md

• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06i-Testing-Code-

Quality-and-Build-Settings.md


• OWASPMobileTop10:M7-ClientCodeQuality






V8:ResilienceRequirements

Controlobjective

Thissectioncoversdefense-in-depthmeasuresrecommendedforappsthatprocess,orgiveaccessto,sensitivedataorfunctionality.Lackofanyofthesecontrolsdoesnotcauseavulnerability-

instead,theyaremeanttoincreasetheapp'sresilienceagainstreverseengineeringandspecificclient-sideattacks.

Thecontrolsinthissectionshouldbeappliedasneeded,basedonanassessmentoftheriskscausedbyunauthorizedtamperingwiththeappand/orreverseengineeringofthecode.We

suggestconsultingtheOWASPdocument"TechnicalRisksofReverseEngineeringand

UnauthorizedCodeModificationReverseEngineeringandCodeModificationPrevention"(see

referencesbelow)foralistbusinessrisksaswellasassociatedtechnicalthreats.

Foranyofthecontrolsinthelistbelowtobeeffective,theappmustfulfilatleastallofMASVS-L1

(i.e.,solidsecuritycontrolsmustbeinplace),aswellasalllower-numberedrequirementsinV8.Forexamples,theobfuscationcontrolslistedinunder"impedecomprehension"mustbecombined

with"appisolation","impededynamicanalysisandtampering"and"devicebinding".

Notethatsoftwareprotectionsmustneverbeusedasareplacementforsecuritycontrols.ThecontrolslistedinMASVR-Rareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSsecurityrequirements.

Thefollowingconsiderationsapply:

i. Athreatmodelmustbedefinedthatclearlyoutlinestheclient-sidethreatsdefendedagainst.Additionally,thegradeofprotectiontheschemeismeanttoprovidemustbespecified.Forexample,astatedgoalcouldbetoforceauthorsoftargetedmalwareseekingtoinstrumenttheapptoinvestsignificantmanualreverseengineeringeffort.

ii. Thethreatmodelmustbesensical.Forexample,hidingacryptographickeyinawhite-boximplementationisbesidesthepointiftheattackercansimplycode-liftthewhite-boxasawhole.

iii. Theeffectivenessoftheprotectionshouldalwaysbeverifiedbyahumanexpertwithexperienceintestingtheparticulartypesofanti-tamperingandobfuscationused(seealsothe"reverseengineering"and"assessingsoftwareprotections"chaptersintheMobileSecurityTestingGuide).

ImpedeDynamicAnalysisandTampering# Description R

8.1 Theappdetects,andrespondsto,thepresenceofarootedorjailbrokendeviceeitherbyalertingtheuserorterminatingtheapp.

�

8.2 Theapppreventsdebuggingand/ordetects,andrespondsto,adebuggerbeing

attached.Allavailabledebuggingprotocolsmustbecovered.�

8.3 Theappdetects,andrespondsto,tamperingwithexecutablefilesandcriticaldatawithinitsownsandbox.

�


8.4 Theappdetects,andrespondsto,thepresenceofwidelyusedreverseengineering

toolsandframeworksonthedevice.�

8.5 Theappdetects,andrespondsto,beingruninanemulator. �

8.6 Theappdetects,andrespondsto,tamperingthecodeanddatainitsownmemory

space.�

8.7 Theappimplementsmultiplemechanismsineachdefensecategory(8.1to8.6).Notethatresiliencyscaleswiththeamount,diversityoftheoriginalityofthemechanisms

used.

�

8.8 Thedetectionmechanismstriggerresponsesofdifferenttypes,includingdelayedandstealthyresponses.

�

8.9 Obfuscationisappliedtoprogrammaticdefenses,whichinturnimpedede-obfuscationviadynamicanalysis.

�

DeviceBinding# Description R

8.10 Theappimplementsa'devicebinding'functionalityusingadevicefingerprintderivedfrommultiplepropertiesuniquetothedevice.

�

ImpedeComprehension# Description R

8.11 Allexecutablefilesandlibrariesbelongingtotheappareeitherencryptedonthefileleveland/orimportantcodeanddatasegmentsinsidetheexecutablesareencrypted

orpacked.Trivialstaticanalysisdoesnotrevealimportantcodeordata.

�

8.12 Ifthegoalofobfuscationistoprotectsensitivecomputations,anobfuscationschemeisusedthatisbothappropriatefortheparticulartaskandrobustagainstmanualand

automatedde-obfuscationmethods,consideringcurrentlypublishedresearch.The

effectivenessoftheobfuscationschememustbeverifiedthroughmanualtesting.

Notethathardware-basedisolationfeaturesarepreferredoverobfuscationwheneverpossible.

�

References


• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-

Resiliency-Against-Reverse-Engineering.md

• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-

Resiliency-Against-Reverse-Engineering.md


• OWASPMobileTop10:M8-CodeTampering,M9-ReverseEngineering

• WASPReverseEngineeringThreats-https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthoriz

ed_Code_Modification


• OWASPReverseEngineeringandCodeModificationPrevention-

https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Pre

vention_Project


AppendixA:Glossary• 2FA–Two-factorauthentication(2FA)addsasecondlevelofauthenticationtoanaccountlog-

in.

• AddressSpaceLayoutRandomization(ASLR)–Atechniquetomakeexploitingmemorycorruptionbugsmoredifficult.

• ApplicationSecurity–Application-levelsecurityfocusesontheanalysisofcomponentsthatcomprisetheapplicationlayeroftheOpenSystemsInterconnectionReferenceModel(OSI

Model),ratherthanfocusingonforexampletheunderlyingoperatingsystemorconnectednetworks.

• ApplicationSecurityVerification–ThetechnicalassessmentofanapplicationagainsttheOWASPMASVS.

• ApplicationSecurityVerificationReport–Areportthatdocumentstheoverallresultsandsupportinganalysisproducedbytheverifierforaparticularapplication.

• Authentication–Theverificationoftheclaimedidentityofanapplicationuser.• AutomatedVerification–Theuseofautomatedtools(eitherdynamicanalysistools,static

analysistools,orboth)thatusevulnerabilitysignaturestofindproblems.

• Blackboxtesting–Itisamethodofsoftwaretestingthatexaminesthefunctionalityofanapplicationwithoutpeeringintoitsinternalstructuresorworkings.

• Component–aself-containedunitofcode,withassociateddiskandnetworkinterfacesthatcommunicateswithothercomponents.

• Cross-SiteScripting(XSS)–Asecurityvulnerabilitytypicallyfoundinwebapplicationsallowingtheinjectionofclient-sidescriptsintocontent.

• Cryptographicmodule–Hardware,software,and/orfirmwarethatimplementscryptographicalgorithmsand/orgeneratescryptographickeys.

• CWE-CWEisacommunity-developedlistofcommonsoftwaresecurityweaknesses.Itservesasacommonlanguage,ameasuringstickforsoftwaresecuritytools,andasabaselinefor

weaknessidentification,mitigation,andpreventionefforts.

• DAST–Dynamicapplicationsecuritytesting(DAST)technologiesaredesignedtodetectconditionsindicativeofasecurityvulnerabilityinanapplicationinitsrunningstate.

• DesignVerification–Thetechnicalassessmentofthesecurityarchitectureofanapplication.• DynamicVerification–Theuseofautomatedtoolsthatusevulnerabilitysignaturestofind

problemsduringtheexecutionofanapplication.

• GloballyUniqueIdentifier(GUID)–auniquereferencenumberusedasanidentifierinsoftware.

• HyperTextTransferProtocol(HTTP)–Anapplicationprotocolfordistributed,collaborative,hypermediainformationsystems.Itisthefoundationofdatacommunicationfor

theWorldWideWeb.

• Hardcodedkeys–Cryptographickeyswhicharestoredinthedeviceitself.• IPC–InterProcessCommunications,InIPCProcessescommunicatewitheachotherandwith

thekerneltocoordinatetheiractivities.

• InputValidation–Thecanonicalizationandvalidationofuntrusteduserinput.• JAVABytecode-JavabytecodeistheinstructionsetoftheJavavirtualmachine(JVM).Each

bytecodeiscomposedofone,orinsomecasestwobytesthatrepresenttheinstruction

(opcode),alongwithzeroormorebytesforpassingparameters.


• MaliciousCode–Codeintroducedintoanapplicationduringitsdevelopmentunbeknownsttotheapplicationowner,whichcircumventstheapplication'sintendedsecuritypolicy.Notthe

sameasmalwaresuchasavirusorworm!

• Malware–Executablecodethatisintroducedintoanapplicationduringruntimewithouttheknowledgeoftheapplicationuseroradministrator.

• OpenWebApplicationSecurityProject(OWASP)–TheOpenWebApplicationSecurityProject(OWASP)isaworldwidefreeandopencommunityfocusedonimprovingthesecurityofapplicationsoftware.Ourmissionistomakeapplicationsecurity"visible,"sothatpeople

andorganizationscanmakeinformeddecisionsaboutapplicationsecurityrisks.See:

http://www.owasp.org/

• PersonallyIdentifiableInformation(PII)-isinformationthatcanbeusedonitsownorwithotherinformationtoidentify,contact,orlocateasingleperson,ortoidentifyan

individualincontext.

• PIE–Position-independentexecutable(PIE)isabodyofmachinecodethat,beingplacedsomewhereintheprimarymemory,executesproperlyregardlessofitsabsoluteaddress.

• PKI–APKIisanarrangementthatbindspublickeyswithrespectiveidentitiesofentities.Thebindingisestablishedthroughaprocessofregistrationandissuanceofcertificatesatandbya

certificateauthority(CA).

• SAST–Staticapplicationsecuritytesting(SAST)isasetoftechnologiesdesignedtoanalyzeapplicationsourcecode,bytecodeandbinariesforcodinganddesignconditionsthatare

indicativeofsecurityvulnerabilities.SASTsolutionsanalyzeanapplicationfromthe“inside

out”inanonrunningstate.

• SDLC–Softwaredevelopmentlifecycle.• SecurityArchitecture–Anabstractionofanapplication'sdesignthatidentifiesanddescribes

whereandhowsecuritycontrolsareused,andalsoidentifiesanddescribesthelocationand

sensitivityofbothuserandapplicationdata.

• SecurityConfiguration–Theruntimeconfigurationofanapplicationthataffectshowsecuritycontrolsareused.

• SecurityControl–Afunctionorcomponentthatperformsasecuritycheck(e.g.anaccesscontrolcheck)orwhencalledresultsinasecurityeffect(e.g.generatinganauditrecord).

• SQLInjection(SQLi)–Acodeinjectiontechniqueusedtoattackdatadrivenapplications,inwhichmaliciousSQLstatementsareinsertedintoanentrypoint.

• SSOAuthentication–SingleSignOn(SSO)occurswhenauserlogsintooneClientandisthensignedintootherClientsautomatically,regardlessoftheplatform,technology,ordomainthe

userisusing.Forexamplewhenyouloginingoogleyouautomaticallyloginintheyoutube,

docsandmailservice.

• ThreatModeling-Atechniqueconsistingofdevelopingincreasinglyrefinedsecurityarchitecturestoidentifythreatagents,securityzones,securitycontrols,andimportant

technicalandbusinessassets.

• TransportLayerSecurity–CryptographicprotocolsthatprovidecommunicationsecurityovertheInternet

• URI/URL/URLfragments–AUniformResourceIdentifierisastringofcharactersusedtoidentifyanameorawebresource.AUniformResourceLocatorisoftenusedasareferencetoaresource.

• Useracceptancetesting(UAT)–Traditionallyatestenvironmentthatbehavesliketheproductionenvironmentwhereallsoftwaretestingisperformedbeforegoinglive.


• Verifier–ThepersonorteamthatisreviewinganapplicationagainsttheOWASPASVSrequirements.

• Whitelist–Alistofpermitteddataoroperations,forexamplealistofcharactersthatareallowedtoperforminputvalidation.

• X.509Certificate–AnX.509certificateisadigitalcertificatethatusesthewidelyacceptedinternationalX.509publickeyinfrastructure(PKI)standardtoverifythatapublickeybelongs

totheuser,computerorserviceidentitycontainedwithinthecertificate.


AppendixB:References

ThefollowingOWASPprojectsaremostlikelytobeusefultousers/adoptersofthisstandard:

• OWASPMobileSecurityProject-

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project

• OWASPMobileSecurityTestingGuide-

https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide

• OWASPMobileTop10Risks-

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-

_Top_Ten_Mobile_Risks

• OWASPReverseEngineeringandCodeModificationPrevention-

https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project

Similarly,thefollowingwebsitesaremostlikelytobeusefultousers/adoptersofthisstandard:

• MITRECommonWeaknessEnumeration-http://cwe.mitre.org/

• PCISecurityStandardsCouncil-https://www.pcisecuritystandards.org

• PCIDataSecurityStandard(DSS)v3.0RequirementsandSecurityAssessmentProcedures

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

FOREWORD BY BERNHARD MUELLER, OWASP MOBILE PROJECT 5 · owasp's stance on masvs certifications and trust marks 12 guidance for certifying mobile apps 12 using the owasp mobile security

Documents