Требуется сделать мобильное приложение, в котором будет система кешбека. Приложение будет подключаться к сайту, сделанному на одном из популярных PHP CMS. Переписать API на другом языке накладко. Есть опасение, что злоумышленник найдет урл к API, узнает что он сделан на пхп и найдет способ взломать. Насколько известно, урл к АПИ можно вычислить. Поэтому можно ли сделать так например, написать промежуточный апи (на питоне, гоу), который в свою очередь будет обращаться на другой адрес (на сайт пхп) и взаимодействовать с ним? При этом перенаправление как мне кажется уже нельзя будет узнать.
Какая разница на чем написано (PHP/Python/Go)? Написать можно как плохо так и хорошо на всем. Вычислить URL к API вообще не проблема. Сделать перенаправление тоже, но если это тупое перенаправление, чем это спасет? Как вы решите проблему с авторизацией, если у вас будут разные сервисы (один на Go, другой на PHP)? Вы себе больше проблем создадите.
dind, чем защитит просто перенаправлять запросы, если скажем то, куда вы их перенаправляете - уязвимо? Если вы что-то там защитите на стороне Python, почему это же самое нельзя защитить на PHP?
Таким образом вы не только не решаете проблему, но ещё и усложняете систему, прежде всего для себя. Для злоумышленника все останется ровно также как было.
ну питон взломать сложнее, а перенаправление внутри кода же происходит, тоесть никто не будет знать, что данные вообще в другом месте. Просто опасаюсь пхп %)
Смотрите поменьше видео типа "Как взломать любой сайт на PHP", которое рекламирует курсы по Java. 60% веб-сервисов (не помню где эту цифру видел) написано на PHP и всё нормально. Писать надо головой и руками просто, а не одним местом.
Сделайте подписанный url и сильно не беспокойтесь. Просто передавайте вместе с URL некий сессионный ключ, который будете генерировать на основе например MD5.
А еще лучше - сделайте отдельный микросервис для вашей задачи! Можно и на PHP.
dind, Нет, я немного не про то (не про https, хотя он к месту!).
У вас есть логин/пароль (или как вы там авторизуете) и некий сервис (скрипт) авторизации или страничка пользователя. Вот в этом скрипте и генерируйте токен, например на 10 минут/дней/лет (или навсегда), и выдавайте его пользователю.
У вас есть url /api/endpoint для вашего API, и пользователь с этим токеном будет к вашему API обращаться как
Вы можете погуглить в сторону Web Application Firewall (WAF), помимо банального скрытия финального сервера с API как бонус получите защиту от распространенных атак.
Но это не значит, что можно полностью довериться WAF и не предпринимать никаких шагов на уровне API ;)
PS: в этой схеме крайне желательно, чтобы финальный API-сервер не отвечал на запросы не от WAF, но это совсем другая история.