Хотел бы собрать во едино список, где бы отражалось то, что не стоит делать, да бы не ругался Security scanner:
- Не оставлять в коде System.debug (что бы потом пользователи случайно не увидели не нужную для них инфу в дебаге)
- Выставлять LIMITS на запросы
- SOQL SOSL Injection (защититься от них)
- Sharing - верное проставлены
- Multiple triggers on same sObject
- Bulkify Apex Methods - Using Collections in methods
- Добавлять Asserts в тест методах
- покрытие тест методами выше 75%
Поделитесь пожайлуйста другими вариациями того, что надо заранее учесть, что бы не ругался Security scanner. И еще Будет просьба пояснить кто его делает и когда.
В общем хотелось бы побольше информации что бы на эту тему аккамулировалось тут.
+ интересует платность и бесплатность этого процесса
Спасибо за подборку, но вот что смутило 
Еще хочу добавить:
- если есть интеграция, то в Remote Site только https
- если хранятся пароли от внешних сервисов, то хранить только в private custom labels (или encripted custom fields, про это не уверен) чтобы только пакет имел доступ к этому полю.
Самое зло забыл - SOQL in Loop
настройки Sharing слишком обобщенно - наверное это больше проблема пакета, сканер тут не заругается.
На что точно ругаются - если перед DML операцией нет проверки на GRUD и FLS!!!
(привет все кто так делает)Если не ошибаюсь то можно запустить сканер вот с етого сайта.
Процес бесплатен, но сканер можно кажись запускать только раз в сутки(хотя не уверен). Примерно через час, полтора приходить на почту pdf и xml отчет.
Вот еще в коде нельзя использовать harcode id, ну ето впринципе и так понятно.
Вот только сканер, как мне показалось не совсем коректно обработал некоторие моменти: например я в тестах использую методи-хелпери, так сканер заругался, что мол в хелп-методах нет ассертов. Пришлось писать
System.assert(true, 'for security scanner');
Вопрос: а как например сделать "SELECT COUNT()"?
Вот сканнер заругался что мол нужно лимит указать.
Сделал через Database.countQuery но потом сканер не запускал.
Я же правильно понимаю, что нужно перед каждым DML проверять есть ли в нас доступ?
public PageReference Save() {
// Enforcing CRUD
if (!Accont.sObjectType.getDescribe().isUpdateable()){
// TODO: Insufficient access
return null;
} // Enforcing FLS
if (!Accont.sObjectType.Contact.fields.Site.isUpdateable()){
// TODO: Insufficient access
return null;
}
Account.Site = 'Bla bla bla';
update account;
return null;
}
Просто никогда этого не делал, и scanner не ругался.
А перед SOQL получается нужно проверять FLS?
public String Save() {
if (!Accont.sObjectType.Contact.fields.Name.isAccessible()){
// TODO: Insufficient access
return null;
} Account[] account = [SELECT Id, Name FROM Account WHERE Id = :acc.Id];
if (!account.isEmpty) {
return account[0].Name;
} else {
// TODO: ???
}
return null;
}
Вот старая добрая стать на эту тему.
Enforcing CRUD and FLS
Вот еще что-то google мне выдал из свежего. Может что интересное там есть?
New Security Review Rule for enforcing FLS and CRUD Checks in Custom Controllers
Смысл в проверке перед DML операцией - предотвратить exception и правильно отреагировать на ограничение прав доступа.